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A gestión de bases de datos ha evolucionado desde una aplicación informática especia¬ 


lizada hasta una parte esencial de un entorno informático moderno y, como resultado, 


E J el conocimiento acerca de los sistemas de bases de datos se ha convertido en una parte 
esencial en la enseñanza de la informática. En este libro se presentan los conceptos fundamen¬ 
tales de la administración de bases de datos. Estos conceptos incluyen aspectos de diseño de 
bases de datos, lenguajes de bases de datos e implementación de sistemas de bases de datos. 

Este libro está orientado a un primer curso de bases de datos para niveles técnicos y supe¬ 
riores. Además del material básico para un primer curso, el texto también contiene temas que 
pueden usarse como complemento del curso o como material introductorio de un curso avan¬ 
zado. 

En este libro se asume que se dispone de los conocimientos elementales sobre estructuras de 
datos básicas, organización de computadoras y un lenguaje de programación de alto nivel (tipo 
Pascal). Los conceptos se presentan usando descripciones intuitivas, muchas de las cuales están 
basadas en el ejemplo propuesto de una empresa bancada. Se tratan los resultados teóricos 
importantes, pero se omiten las demostraciones formales. Las notas bibliográficas contienen 
referencias a artículos de investigación en los que los resultados se presentaron y probaron, y 
también referencias a material para otras lecturas. En lugar de demostraciones, se usan figuras 
y ejemplos para sugerir por qué se espera que los resultados en cuestión sean ciertos. 

Los conceptos fundamentales y algoritmos tratados en este libro se basan habitualmente en 
los que se usan en la actualidad en sistemas de bases de datos existentes, comerciales o expe¬ 
rimentales. Nuestro deseo es presentar estos conceptos y algoritmos como un conjunto general 
que no esté ligado a un sistema de bases de datos particular. En la Parte 8 se discuten detalles 
de sistemas de bases de datos comerciales. 

En esta cuarta edición de Fundamentos de bases de datos se ha mantenido el estilo global 
de las primeras tres ediciones, a la vez que se ha tenido en cuenta la evolución de la gestión de 
bases de datos. Se han añadido varios capítulos nuevos para tratar nuevas tecnologías. Cada 
capítulo se ha corregido y la mayoría se ha modificado ampliamente. Se describirán los cam¬ 
bios con detalle en breve. 


ORGANIZACIÓN 

El texto está organizado en ocho partes principales más dos apéndices: 

• Visión general (Capítulo 1). En el Capítulo 1 se proporciona una visión general de la natu¬ 
raleza y propósito de los sistemas de bases de datos. Se explica cómo se ha desarrollado el 
concepto de sistema de bases de datos, cuáles son las características usuales de los sistemas 
de bases de datos, lo que proporciona al usuario un sistema de bases de datos y cómo un sis¬ 
tema de bases de datos se comunica con los sistemas operativos. También se introduce una 
aplicación de bases de datos de ejemplo: una empresa bancaria que consta de muchas sucur¬ 
sales. Este ejemplo se usa a lo largo de todo el libro. Este capítulo es histórico, explicativo y 
motivador por naturaleza. 

• Modelos de datos (Capítulos 2 y 3). En el Capítulo 2 se presenta el modelo entidad-relación. 
Este modelo proporciona una visión de alto nivel de los resultados de un diseño de base de 
datos y de los problemas que se encuentran en la captura de la semántica de las aplicaciones 
realistas que contienen las restricciones de un modelo de datos. El Capítulo 3 se centra en el 
modelo de datos relacional, tratando la relevancia del álgebra relacional y el cálculo rela- 
cional. 

• Bases de datos relaciónales (Capítulos 4 al 7). El Capítulo 4 se centra en el lenguaje rela¬ 
cional orientado al usuario de mayor influencia: SQL. El Capítulo 5 cubre otros dos lengua¬ 
jes relaciónales, QBE y Datalog. En estos dos capítulos se describe la manipulación de datos: 
consultas, actualizaciones, inserciones y borrados. Los algoritmos y las cuestiones de diseño 
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se relegan a capítulos posteriores. Así, estos capítulos son adecuados para aquellas personas 
o para las clases de nivel más bajo en donde se desee aprender qué es un sistema de bases de 
datos, sin entrar en detalles sobre los algoritmos internos y estmcturas que contienen. 

En el Capítulo 6 se presentan las restricciones desde el punto de vista de la integridad de 
las bases de datos. En el Capítulo 7 se muestra cómo se pueden usar las restricciones en el 
diseño de una base de datos relacional. En el Capítulo 6 se presentan la integridad referen- 
cial; mecanismos para el mantenimiento de la integridad, tales como disparadores y asertos, 
y mecanismos de autorización. El tema de este capítulo es la protección de las bases de datos 
contra daños accidentales y daños intencionados. 

En el Capítulo 7 se introduce la teoría del diseño de bases de datos relaciónales. Se trata 
la teoría de las dependencias funcionales y la normalización, con énfasis en la motivación y 
el significado intuitivo de cada forma normal. También se describe en detalle el proceso de 
diseño de bases de datos. 

• Bases de datos basadas en objetos y XML (Capítulos 8 al 10). El Capítulo 8 trata las bases 
de datos orientadas a objetos. En él se introducen los conceptos de la programación orien¬ 
tada a objetos y se muestra cómo estos conceptos constituyen la base para un modelo de datos. 
No se asume un conocimiento previo de lenguajes orientados a objetos. El Capítulo 9 trata 
las bases de datos relaciónales de objetos, y muestra cómo la norma SQL: 1999 extiende el 
modelo de datos relacional para incluir características de la programación orientada a obje¬ 
tos, tales como la herencia, los tipos complejos y la identidad de objeto. 

En el Capítulo 10 se trata la norma XML para representación de datos, el cual está expe¬ 
rimentando un uso cada vez mayor en la comunicación de datos y en el almacenamiento de 
tipos de datos complejos. El capítulo también describe lenguajes de consulta para XML. 

• Almacenamiento de datos y consultas (Capítulos 11 al 14). En el Capítulo 11 se estudian los 
discos, archivos y estmcturas de un sistema de archivos y la correspondencia de datos relació¬ 
nales y de objetos con un sistema de archivos. En el Capítulo 12 se presentan varias técnicas de 
acceso a los datos, incluyendo la asociación, los índices de árboles B+ y los índices de archivos 
en retícula. Los capítulos 13 y 14 tratan los algoritmos de evaluación de consultas y optimiza¬ 
ción de consultas basados en transformación de consultas preservando la equivalencia. 

Estos capítulos están orientados a personas que desean conocer los componentes de alma¬ 
cenamiento y consulta internos de una base de datos. 

• Gestión de transacciones (Capítulos 15 al 17). El Capítulo 15 se centra en los fundamentos 
de un sistema de procesamiento de transacciones, incluyendo la atomicidad de las transaccio¬ 
nes, la consistencia, el aislamiento y la durabilidad, y también la noción de secuencialidad. 

El Capítulo 16 se centra en el control de concurrencia y se presentan varias técnicas que 
aseguran la secuencialidad, incluyendo los bloqueos, las marcas temporales y técnicas opti¬ 
mistas (de validación). Los temas de interbloqueo se tratan también en este capítulo. El Capí¬ 
tulo 17 aborda las técnicas principales para asegurar la ejecución correcta de transacciones a 
pesar de las caídas del sistema y los fallos de disco. Estas técnicas incluyen el registro histó¬ 
rico, paginación en la sombra, puntos de revisión y volcados de la base de datos. 

• Arquitectura de un sistema de bases de datos (Capítulos 18 al 20). El Capítulo 18 trata la 
arquitectura de un sistema informático y en él se describe la influencia de los sistemas infor¬ 
máticos subyacentes en los sistemas de bases de datos. Se discuten los sistemas centraliza¬ 
dos, los sistemas cliente-servidor, las arquitecturas paralelas y distribuidas, y los tipos de 
redes. En el Capítulo 19 se estudian los sistemas de bases de datos distribuidas, revisando los 
aspectos de diseño de bases de datos, gestión de las transacciones y evaluación y optimiza¬ 
ción de consultas en el contexto de los sistemas de bases de datos distribuidas. El capítulo 
también trata aspectos de la disponibilidad del sistema durante fallos y describe el sistema de 
directorios LDAP. 

En el capítulo 20, acerca de las bases de datos paralelas, se exploran varias técnicas de 
paralelización, incluyendo paralelismo de E/S, paralelismo entre consultas y en consultas, y 
paralelismo entre operaciones y en operaciones. También se describe el diseño de sistemas 
paralelos. 

• Otros temas (Capítulos 21 al 24). El Capítulo 21 trata el desarrollo y administración de apli¬ 
caciones de bases de datos. Los temas incluyen las interfaces de las bases de datos, en par¬ 
ticular las interfaces Web, el ajuste de rendimiento, los programas de prueba, la estandariza¬ 
ción y los aspectos de las bases de datos en el comercio electrónico. El Capítulo 22 presenta 


XVIII 


PREFACIO 


técnicas de consulta, incluyendo sistemas de ayuda a la toma de decisiones y recuperación 
de la información. Los temas tratados en el área de la ayuda a la toma de decisiones incluyen 
las técnicas de procesamiento analítico interactivo (OLAP, Online Analytical Processing), el 
soporte de SQL: 1999 para OLAP, recopilación de datos y almacenes de datos. El capítulo 
también describe técnicas de recuperación de información para la consulta de datos textua¬ 
les, incluyendo técnicas basadas en hipervínculos usadas en los motores de búsqueda Web. 

El Capítulo 23 trata tipos de datos avanzados y nuevas aplicaciones, incluyendo datos tem¬ 
porales, datos espaciales y geográficos, datos multimedia, y aspectos de la gestión de las bases 
de datos móviles y personales. Finalmente, el Capítulo 24 trata el procesamiento avanzado de 
transacciones. Se estudian los monitores de procesamiento de transacciones, los sistemas 
de transacciones de alto rendimiento, los sistemas de transacciones de tiempo real, y los flu¬ 
jos de datos transaccionales. 

• Estudios de casos (Capítulos 25 al 27). En esta parte presentamos estudios de casos de tres 
sistemas de bases de datos comerciales: Oracle, IBM DB2 y Microsoft SQL Server. Estos 
capítulos esbozan características únicas de cada uno de los productos y describen su estruc¬ 
tura intema. Proporcionan una gran cantidad de información interesante sobre los productos 
respectivos, y ayudan a ver cómo las diferentes técnicas de implementación descritas en las 
partes anteriores se usan en sistemas reales. También se tratan aspectos prácticos en el diseño 
de sistemas reales. 

• Apéndices en línea. Aunque la mayoría de las aplicaciones de bases de datos modernas usen, 
bien el modelo relacional o bien el modelo orientado a objetos, los modelos de datos de redes 
y jerárquico están en uso todavía. En beneficio de los lectores que deseen aprender estos 
modelos de datos se proporcionan apéndices que describen los modelos de redes y jerárquico, 
en los Apéndices A y B, respectivamente. Los apéndices sólo están disponibles en Internet 
(http://www.bell-labs.com/topic/books/db-book). 

El Apéndice C describe el diseño avanzado de bases de datos relaciónales, incluyendo la 
teoría de dependencias multivaloradas ¿Multivaluadas?, las dependencias de reunión y las 
formas normales de proyección-reunión y dominio-clave. Este apéndice es útil para quienes 
deseen el tratamiento del diseño de bases de datos relaciónales en más detalle, y para profe¬ 
sores que deseen explicarlo en sus asignaturas. Este apéndice está también sólo disponible 
en Internet, en la página Web del libro. 


LA CUARTA EDICIÓN 

La producción de esta cuarta edición se ha guiado por muchos comentarios y sugerencias refe¬ 
ridos a las ediciones anteriores, junto con las propias observaciones en la enseñanza en el I1T 
de Bombay, y por el análisis de las direcciones que la tecnología de bases de datos está tomando. 

El procedimiento básico fue reescribir el material en cada capítulo, actualizando el material 
más antiguo, añadiendo discusiones en desarrollos recientes en la tecnología de bases de datos, 
y mejorando las descripciones de los temas que los estudiantes encontraron difíciles de com¬ 
prender. Cada capítulo tiene ahora una lista de términos de repaso, que pueden ayudar a asi¬ 
milar los temas clave tratados en cada capítulo. Se ha añadido también una nueva sección al 
final de la mayoría de los capítulos que proporciona información sobre herramientas software 
referidas al tema del capítulo. También se han añadido nuevos ejercicios y se han actualizado 
las referencias. 

Se ha incluido un nuevo capítulo que trata XML, y tres capítulos de estudio de los sistemas 
de bases de datos comerciales líderes: Oracle, IBM DB2 y Microsoft SQL Server. 

Los capítulos se han organizado en varias partes y se han reorganizado los contenidos de 
varios de ellos. En beneficio de aquellos lectores familiarizados con la tercera edición se expli¬ 
can a continuación los principales cambios. 

• Modelo entidad-relación. Se ha mejorado el tratamiento del modelo entidad-relación (E-R). 
Se han añadido nuevos ejemplos y algunos se han cambiado para dar una mejor intuición al 
lector. Se ha incluido un resumen de notaciones E-R alternativas, junto con un nuevo apar¬ 
tado sobre UML. 

• Bases de datos relaciónales. El tratamiento de SQL en el Capítulo 4 ahora se refiere al están¬ 
dar SQL: 1999, que se aprobó después de la publicación de la tercera edición de este libro. El 
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tratamiento de SQL se ha ampliado significativamente para incluir la cláusula with, para un 
tratamiento ampliado de SQL incorporado y el tratamiento de ODBC y JDBC, cuyo uso ha 
aumentado notablemente en los últimos años. La parte del capítulo 5 dedicada a Quel se ha eli¬ 
minado, ya que no se usa ampliamente debido al poco uso que actualmente se hace de este 
lenguaje. El tratamiento de QBE se ha revisado para eliminar algunas ambigüedades y para 
añadir el tratamiento de la versión de QBE usada en la base de datos Microsoft Access. 

El Capítulo 6 trata ahora de las restricciones de integridad y de la seguridad. El tratamiento 
de la seguridad, ubicado en la edición anterior en el Capítulo 19, se ha trasladado al Capítu¬ 
lo 6. El Capítulo 6 también trata los disparadores. El Capítulo 7 aborda el diseño de las bases 
de datos relaciónales y las formas normales. La discusión de las dependencias funcionales, 
ubicada en la edición anterior en el Capítulo 6, se ha trasladado al Capítulo 7. El Capítulo 7 
se ha remodelado significativamente, proporcionando varios algoritmos para las dependen¬ 
cias funcionales y un tratamiento extendido del proceso general del diseño de bases de datos. 
Los axiomas para la inferencia de las dependencias multivaloradas, las formas normales FNRP 
y FNCD se han trasladado al apéndice. 

• Bases de datos basadas en objetos. Se ha mejorado el tratamiento de la orientación a obje¬ 
tos del Capítulo 8, y se ha actualizado la discusión de ODMG. Se ha actualizado el trata¬ 
miento de las bases de datos relaciónales orientadas a objetos del Capítulo 9 y, en particular, 
el estándar SQL: 1999, reemplaza a SQL extendido usado en la tercera edición. 

• XML. El Capítulo 10, que trata XML, es un nuevo capítulo de la cuarta edición. 

• Almacenamiento, ¡ndexación y procesamiento de consultas. Se ha actualizado el trata¬ 
miento del almacenamiento y de las estructuras de archivos del Capítulo 11; este fue el Capí¬ 
tulo 10 en la tercera edición. Muchas características de las unidades de disco y de otros 
mecanismos de almacenamiento han cambiado en gran medida con el paso de los años, y su 
tratamiento se ha actualizado correspondientemente. El tratamiento de RAID se ha actuali¬ 
zado para reflejar las tendencias tecnológicas. El tratamiento de diccionarios de datos (catá¬ 
logos) se ha extendido. 

El Capítulo 12, sobre indexación, incluye ahora el estudio de los índices de mapa de bits; 
este capítulo fue el Capítulo 11 en la tercera edición. El algoritmo de inserción en árboles B + 
se ha simplificado y se ha proporcionado un pseudocódigo para su examen. La asociación 
dividida se ha eliminado, ya que no tiene un uso significativo. 

El tratamiento del procesamiento de consultas se ha reorganizado, con el capítulo anterior 
(Capítulo 12 en la tercera edición) dividido en dos capítulos, uno sobre procesamiento de 
consultas (Capítulo 13) y otro sobre optimización de consultas (Capítulo 14). Todos los deta¬ 
lles referidos a la estimación de costes y a la optimización de consultas se han trasladado al 
Capítulo 14, permitiendo al Capítulo 13 centrarse en los algoritmos de procesamiento de con¬ 
sultas. Se han eliminado varias fórmulas detalladas (y tediosas) para el cálculo del número 
exacto de operaciones de E/S para diferentes operaciones. El Capítulo 14 se presenta ahora 
con un pseudocódigo para la optimización de algoritmos, y nuevos apartados sobre la opti¬ 
mización de subconsultas anidadas y sobre vistas materializadas. 

• Procesamiento de transacciones. El Capítulo 15, que proporciona una introducción a las 
transacciones, se ha actualizado; este capítulo era el Capítulo 13 en la tercera edición. Se han 
eliminado los tests de secuenciabilidad. 

El Capítulo 16, sobre el control de concurrencia, incluye un nuevo apartado sobre la imple- 
mentación de los gestores de bloqueo, y otro sobre los niveles débiles de consistencia, que 
estaban en el Capítulo 20 de la tercera edición. Se ha ampliado el control de concurrencia de 
estructuras de índices, proporcionando detalles del protocolo cangrejo, que es una alterna¬ 
tiva más simple al protocolo de enlace B, y el bloqueo de siguiente clave para evitar el pro¬ 
blema fantasma. El Capítulo 17, que trata sobre recuperación, incluye ahora un estudio del 
algoritmo de recuperación ARIES. Este capítulo trata ahora los sistemas de copia de seguri¬ 
dad remota para proporcionar una alta disponibilidad a pesar de los fallos, característica cada 
vez más importante en las aplicaciones «24x7». 

Como en la tercera edición, esta organización permite a los profesores elegir entre con¬ 
ceptos de procesamiento de transacciones introductorios únicamente (cubiertos sólo en el 
Capítulo 15) u ofrecer un conocimiento detallado (basado en los Capítulos 15 al 17). 

• Arquitecturas de sistemas de bases de datos. El Capítulo 18, que proporciona una visión 
general de las arquitecturas de sistemas de bases de datos, se ha actualizado para tratar la tec¬ 
nología actual; esto se encontraba en el Capítulo 16 de la tercera edición. El orden del capí- 
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tulo de bases de datos paralelas y de los capítulos de bases de datos distribuidas se ha inter¬ 
cambiado. Mientras que el tratamiento de las técnicas de procesamiento de consultas de bases 
de datos del Capítulo 20 (que fue el Capítulo 16 en la tercera edición) es de primordial inte¬ 
rés para quienes deseen aprender los interiores de las bases de datos, las bases de datos dis¬ 
tribuidas, ahora tratadas en el Capítulo 19, son un tema más fundamental con el que debería 
estar familiarizado cualquiera que trabaje con bases de datos. 

El Capítulo 19 sobre bases de datos distribuidas se ha rehecho significativamente para re¬ 
ducir el énfasis en la denominación y la transparencia, y para aumentar el tratamiento de la 
operación durante fallos, incluyendo las técnicas de control de concurrencia para proporcio¬ 
nar alta disponibilidad. El tratamiento del protocolo de compromiso de tres fases se ha abre¬ 
viado, al tener detección distribuida de interbloqueos globales, ya que no se usa mucho en la 
práctica. El estudio de los aspectos de procesamiento de consultas se ha trasladado del Capítu¬ 
lo 20 de la tercera edición. Hay un nuevo apartado sobre los sistemas de directorio, en parti¬ 
cular LDAP, ya que se usan ampliamente como un mecanismo para hacer disponible la 
información en una configuración distribuida. 

• Otros temas. Aunque se ha modificado y actualizado el texto completo, nuestra presentación 
del material que tiene relación con el continuo desarrollo de bases de datos y las nuevas apli¬ 
caciones de bases de datos se tratan en cuatro nuevos capítulos, del Capítulo 21 al 24. 

El Capítulo 21 es nuevo en la cuarta edición y trata el desarrollo y administración de apli¬ 
caciones. La descripción de la construcción de interfaces Web para bases de datos, incluyendo 
servlets y otros mecanismos para las secuencias de comandos para el lado del servidor, es 
nueva. La sección sobre ajuste de rendimiento, que estaba anteriormente en el Capítulo 19, 
tiene nuevo material sobre la famosa regla de 5 minutos y sobre la regla de 1 minuto, así como 
algunos nuevos ejemplos. El tratamiento de la selección de vistas materializadas también es 
nuevo. El tratamiento de los programas de prueba y de los estándares se ha actualizado. Hay 
una nueva sección sobre comercio electrónico, centrándose en los aspectos de las bases de 
datos en el comercio electrónico y un nuevo apartado que trata los sistemas heredados. 

El Capítulo 22, que trata consultas avanzadas y recuperación de la información, incluye 
nuevo material sobre OLAP, particularmente sobre las extensiones de SQL: 1999 para análi¬ 
sis de datos. El estudio de los almacenes de datos y de la recopilación de datos también se ha 
ampliado en gran medida. El tratamiento de la recuperación de la información se ha aumen¬ 
tado significativamente, en particular en el área de la búsqueda Web. Las versiones anterio¬ 
res de este material estaban en el Capítulo 21 de la tercera edición. 

El Capítulo 23, que trata tipos de datos avanzados y nuevas aplicaciones, contiene mate¬ 
rial sobre datos temporales, datos espaciales, datos multimedia y bases de datos móviles. Este 
material es una versión actualizada del material que se encontraba en el Capítulo 21 de la ter¬ 
cera edición. El Capítulo 24, que trata el procesamiento de transacciones avanzado, contiene 
versiones actualizadas de los monitores TP, sistemas de flujo de datos, bases de datos en 
memoria principal y de tiempo real, transacciones de larga duración y gestión de transaccio¬ 
nes en múltiples bases de datos, que aparecieron en el Capítulo 20 de la tercera edición. 


NOTA PARA EL PROFESOR 

El libro contiene tanto material básico como material avanzado, que podría no ser abordado en 

un único semestre. Se han marcado varios apartados como avanzados, usando el símbolo «**». 

Estos apartados se pueden omitir, si se desea, sin pérdida de continuidad. 

Es posible diseñar cursos usando varios subconjuntos de los capítulos. A continuación se 

muestran varias posibilidades: 

• El Capítulo 5 se puede omitir si los estudiantes no van a usar QBE o Datalog como parte del 
curso. 

• Si la programación orientada a objetos se va a tratar en un curso avanzado por separado, los 
Capítulos 8 y 9 y el Apartado 11.9 se pueden omitir. Alternativamente, con ellos se puede 
constituir la base de un curso avanzado de bases de datos orientadas a objetos. 

• El Capítulo 10 (XML) y el Capítulo 14 (optimización de consultas) se pueden omitir para un 
curso introductorio. 
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• Tanto el tratamiento del procesamiento de transacciones (Capítulos 15 al 17) como de la arqui¬ 
tectura de sistemas de bases de datos (Capítulos 18 al 20) poseen un capítulo de visión de 
conjunto (Capítulos 15 y 18 respectivamente), seguidos de capítulos más detallados. Se podría 
elegir usar los Capítulos 15 y 18, omitiendo los Capítulos 16, 17, 19 y 20, si se relegan estos 
capítulos para un curso avanzado. 

• Los Capítulos 21 al 24 son adecuados para un curso avanzado o para autoaprendizaje de los 
estudiantes, aunque el apartado 21.1 se puede tratar en un primer curso de bases de datos. 

Se puede encontrar un modelo de plan de estudios del curso, a partir del texto, en la página 
inicial Web del libro (véase el siguiente apartado). 


PÁGINA WEB Y SUPLEMENTOS PARA LA ENSEÑANZA 
Está disponible una página World Wide Web para este libro en el URL: 

http://www.bell-labs.com/topic/books/db-book 
La página Web contiene: 

• Transparencias de todos los capítulos del libro. 

• Respuestas a ejercicios seleccionados. 

• Los tres apéndices. 

• Una lista de erratas actualizada. 

• Material suplementario proporcionado por usuarios del libro. 

Se puede proporcionar un manual completo de soluciones sólo a las facultades. Para obte¬ 
ner más información sobre cómo obtener una copia del manual de soluciones envíe por favor 
un correo electrónico a customer.service@mcgraw-hill.com. En los Estados Unidos se puede 
llamar al 800-338-3987. La página Web de McGraw-Hill para este libro es: 

http ://www. m cg raw-h i 11. es/olc/s i I be rsch atz 


CÓMO CONTACTAR CON LOS AUTORES Y OTROS USUARIOS 

Se ha creado una lista de correo electrónico con la que los usuarios de este libro pueden comu¬ 
nicarse entre sí y con los autores. Si desea incorporarse a la lista, por favor mande un mensaje 
a db-book@research.bell-labs.com, incluyendo su nombre, afiliación, puesto y dirección de 
correo electrónico. 

Nos hemos esforzado para eliminar erratas y problemas del texto, pero, como en los nuevos 
desarrollos de software, probablemente queden fallos; hay una lista de erratas actualizada acce¬ 
sible desde la página inicial del libro*. Agradeceríamos que se nos notificara cualquier error u 
omisión del libro que no se encuentre en la lista actual de erratas. 

También desearíamos recibir sugerencias sobre la mejora del libro. Damos la bienvenida a 
aquellas contribuciones a la página Web del libro que pudiesen ser usadas por otros lectores, 
como ejercicios de programación, sugerencias sobre proyectos, laboratorios y tutoriales en línea, 
y consejos de enseñanza. 

El correo electrónico se deberá dirigir a db-book@research.bell-labs.com. Cualquier otra 
correspondencia se debe enviar a Avi Silberschatz, Bell Laboratories, Room 2T-310, 600 Moun- 
tain Avenue, Murray Hill, NJ 07974, EE.UU. 


* N. del T. Todas las erratas de la versión original en inglés incluidas en esta página Web en el momento de fina¬ 
lizar la traducción se han corregido en este libro. 
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U N sistema gestor de bases de datos (SGBD) consiste en una colección de datos inter¬ 
relacionados y un conjunto de programas para acceder a dichos datos. La colección de 
datos, normalmente denominada base de datos, contiene información relevante para 
una empresa. El objetivo principal de un SGBD es proporcionar una forma de almacenar y recu¬ 
perar la información de una base de datos de manera que sea tanto práctica como eficiente. 

Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de información. 
La gestión de los datos implica tanto la definición de estructuras para almacenar la información 
como la provisión de mecanismos para la manipulación de la información. Además, los siste¬ 
mas de bases de datos deben proporcionar la fiabilidad de la información almacenada, a pesar 
de las caídas del sistema o los intentos de acceso sin autorización. Si los datos van a ser com¬ 
partidos entre diversos usuarios, el sistema debe evitar posibles resultados anómalos. 

Dado que la información es tan importante en la mayoría de las organizaciones, los cientí¬ 
ficos informáticos han desarrollado un amplio conjunto de conceptos y técnicas para la gestión 
de los datos. En este capítulo se presenta una breve introducción a los principios de los siste¬ 
mas de bases de datos. 


1.1. APLICACIONES DE LOS SISTEMAS DE BASES DE DATOS 


Las bases de datos son ampliamente usadas. Las si¬ 
guientes son algunas de sus aplicaciones más repre¬ 
sentativas: 

• Banca. Para información de los clientes, cuentas 
y préstamos, y transacciones bancarias. 

• Líneas aéreas. Para reservas e información de pla¬ 
nificación. Las líneas aéreas fueron de los prime¬ 
ros en usar las bases de datos de forma distribui¬ 
da geográficamente (los terminales situados en 
todo el mundo accedían al sistema de bases de 
datos centralizado a través de las líneas telefóni¬ 
cas y otras redes de datos). 

• Universidades. Para información de los estudian¬ 
tes, matrículas de las asignaturas y cursos. 

• Transacciones de tarjetas de crédito. Para com¬ 
pras con tarjeta de crédito y generación mensual 
de extractos. 

• Telecomunicaciones. Para guardar un registro de 
las llamadas realizadas, generación mensual de 
facturas, manteniendo el saldo de las tarjetas tele¬ 
fónicas de prepago y para almacenar información 
sobre las redes de comunicaciones. 

• Finanzas. Para almacenar información sobre gran¬ 
des empresas, ventas y compras de documentos 
formales financieros, como bolsa y bonos. 

• Ventas. Para información de clientes, productos y 
compras. 


• Producción. Para la gestión de la cadena de pro¬ 
ducción y para el seguimiento de la producción de 
elementos en las factorías, inventarios de elemen¬ 
tos en almacenes y pedidos de elementos. 

• Recursos humanos. Para información sobre los em¬ 
pleados, salarios, impuestos y beneficios, y para la 
generación de las nóminas. 

Como esta lista ilustra, las bases de datos forman una 
parte esencial de casi todas las empresas actuales. 

A lo largo de las últimas cuatro décadas del siglo vein¬ 
te, el uso de las bases de datos creció en todas las empre¬ 
sas. En los primeros días, muy pocas personas interac¬ 
tuaron directamente con los sistemas de bases de datos, 
aunque sin darse cuenta interactuaron con bases de datos 
indirectamente (con los informes impresos como extrac¬ 
tos de tarjetas de crédito, o mediante agentes como caje¬ 
ros de bancos y agentes de reserva de líneas aéreas). Des¬ 
pués vinieron los cajeros automáticos y permitieron a los 
usuarios interactuar con las bases de datos. Las interfaces 
telefónicas con los computadores (sistemas de respuesta 
vocal interactiva) también permitieron a los usuarios mane¬ 
jar directamente las bases de datos. Un llamador podía 
marcar un número y pulsar teclas del teléfono para intro¬ 
ducir información o para seleccionar opciones alternati¬ 
vas, para determinar las horas de llegada o salida, por ejem¬ 
plo, o para matricularse de asignaturas en una universidad. 

La revolución de Internet a finales de la década de 
1990 aumentó significativamente el acceso directo del 
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usuario a las bases de datos. Las organizaciones con¬ 
virtieron muchas de sus interfaces telefónicas a las 
bases de datos en interfaces Web, y pusieron disponi¬ 
bles en línea muchos servicios. Por ejemplo, cuando 
se accede a una tienda de libros en línea y se busca un 
libro o una colección de música se está accediendo a 
datos almacenados en una base de datos. Cuando se 
solicita un pedido en línea, el pedido se almacena en 
una base de datos. Cuando se accede a un banco en un 
sitio Web y se consulta el estado de la cuenta y los 
movimientos, la información se recupera del sistema 
de bases de datos del banco. Cuando se accede a un 
sitio Web, la información personal puede ser recupe¬ 
rada de una base de datos para seleccionar los anun¬ 
cios que se deberían mostrar. Más aún, los datos sobre 


los accesos Web pueden ser almacenados en una base 
de datos. 

Así, aunque las interfaces de datos ocultan detalles 
del acceso a las bases de datos, y la mayoría de la gen¬ 
te ni siquiera es consciente de que están interactuando 
con una base de datos, el acceso a las bases de datos for¬ 
ma una parte esencial de la vida de casi todas las per¬ 
sonas actualmente. 

La importancia de los sistemas de bases de datos se 
puede juzgar de otra forma: actualmente, los vendedo¬ 
res de sistemas de bases de datos como Oracle están 
entre las mayores compañías software en el mundo, y 
los sistemas de bases de datos forman una parte impor¬ 
tante de la línea de productos de compañías más diver¬ 
sificadas, como Microsoft e IBM. 


1.2. SISTEMAS DE BASES DE DATOS FRENTE A SISTEMAS DE ARCHIVOS 


Considérese parte de una empresa de cajas de ahorros que 
mantiene información acerca de todos los clientes y cuen¬ 
tas de ahorros. Una manera de mantener la información 
en un computador es almacenarla en archivos del siste¬ 
ma operativo. Para permitir a los usuarios manipular la 
información, el sistema tiene un número de programas 
de aplicación que manipula los archivos, incluyendo: 

• Un programa para efectuar cargos o abonos en una 
cuenta. 

• Un programa para añadir una cuenta nueva. 

• Un programa para calcular el saldo de una cuenta. 

• Un programa para generar las operaciones men¬ 
suales. 

Estos programas de aplicación se han escrito por pro¬ 
gramadores de sistemas en respuesta a las necesidades 
de la organización bancaria. 

Si las necesidades se incrementan, se añaden nuevos 
programas de aplicación al sistema. Por ejemplo, supón¬ 
gase que las regulaciones de un nuevo gobierno permi¬ 
ten a las cajas de ahorros ofrecer cuentas corrientes. 
Como resultado se crean nuevos archivos permanentes 
que contengan información acerca de todas las cuentas 
corrientes mantenidas por el banco, y puede ser necesa¬ 
rio escribir nuevos programas de aplicación para tratar 
situaciones que no existían en las cuentas de ahorro, tales 
como manejar descubiertos. Así, sobre la marcha, se aña¬ 
den más archivos y programas de aplicación al sistema. 

Este sistema de procesamiento de archivos típico 
que se acaba de describir se mantiene mediante un sis¬ 
tema operativo convencional. Los registros permanen¬ 
tes son almacenados en varios archivos y se escriben 
diferentes programas de aplicación para extraer regis¬ 
tros y para añadir registros a los archivos adecuados. 
Antes de la llegada de los sistemas de gestión de bases 
de datos (SGBDs), las organizaciones normalmente han 
almacenado la información usando tales sistemas. 


Mantener información de la organización en un sis¬ 
tema de procesamiento de archivos tiene una serie de 
inconvenientes importantes: 

• Redundancia e inconsistencia de datos. Debido 
a que los archivos y programas de aplicación son 
creados por diferentes programadores en un largo 
período de tiempo, los diversos archivos tienen pro¬ 
bablemente diferentes formatos y los programas 
pueden estar escritos en diferentes lenguajes. Más 
aún, la misma información puede estar duplicada 
en diferentes lugares (archivos). Por ejemplo, la 
dirección y número de teléfono de un cliente parti¬ 
cular puede aparecer en un archivo que contenga 
registros de cuentas de ahorros y en un archivo que 
contenga registros de una cuenta corriente. Esta 
redundancia conduce a un almacenamiento y cos¬ 
te de acceso más altos. Además, puede conducir a 
inconsistencia de datos; es decir, las diversas 
copias de los mismos datos pueden no coincidir. 
Por ejemplo, un cambio en la dirección del cliente 
puede estar reflejado en los registros de las cuentas 
de ahorro pero no estarlo en el resto del sistema. 

• Dificultad en el acceso a los datos. Supóngase que 
uno de los empleados del banco necesita averiguar 
los nombres de todos los clientes que viven en el 
distrito postal 28733 de la ciudad. El empleado pide 
al departamento de procesamiento de datos que 
genere dicha lista. Debido a que esta petición no 
fue prevista cuando el sistema original fue diseña¬ 
do, no hay un programa de aplicación a mano para 
satisfacerla. Hay, sin embargo, un programa de apli¬ 
cación que genera la lista de todos los clientes. El 
empleado del banco tiene ahora dos opciones: bien 
obtener la lista de todos los clientes y obtener la 
información que necesita manualmente, o bien pedir 
al departamento de procesamiento de datos que haga 


2 





CAPÍTULO 1 INTRODUCCIÓN 


que un programador de sistemas escriba el progra¬ 
ma de aplicación necesario. Ambas alternativas son 
obviamente insatisfactorias. Supóngase que se escri¬ 
be tal programa y que, varios días más tarde, el mis¬ 
mo empleado necesita arreglar esa lista para incluir 
sólo aquellos clientes que tienen una cuenta con sal¬ 
do de 10.000 € o más. Como se puede esperar, un 
programa para generar tal lista no existe. De nue¬ 
vo, el empleado tiene que elegir entre dos opcio¬ 
nes, ninguna de las cuales es satisfactoria. 

La cuestión aquí es que el entorno de procesa¬ 
miento de archivos convencional no permite que 
los datos necesarios sean obtenidos de una forma 
práctica y eficiente. Se deben desarrollar sistemas 
de recuperación de datos más interesantes para un 
uso general. 

• Aislamiento de datos. Debido a que los datos 
están dispersos en varios archivos, y los archivos 
pueden estar en diferentes formatos, es difícil escri¬ 
bir nuevos programas de aplicación para recupe¬ 
rar los datos apropiados. 

• Problemas de integridad. Los valores de los datos 
almacenados en la base de datos deben satisfacer 
ciertos tipos de restricciones de consistencia. Por 
ejemplo, el saldo de una cuenta bancaria no puede 
nunca ser más bajo de una cantidad predetermina¬ 
da (por ejemplo 25 €). Los desarrolladores hacen 
cumplir esas restricciones en el sistema añadiendo 
el código apropiado en los diversos programas de 
aplicación. Sin embargo, cuando se añaden nuevas 
restricciones, es difícil cambiar los programas para 
hacer que se cumplan. El problema es complicado 
cuando las restricciones implican diferentes ele¬ 
mentos de datos de diferentes archivos. 

• Problemas de atomicidad. Un sistema de un com¬ 
putador, como cualquier otro dispositivo mecáni¬ 
co o eléctrico, está sujeto a fallo. En muchas apli¬ 
caciones es crucial asegurar que, una vez que un 
fallo ha ocurrido y se ha detectado, los datos se res¬ 
tauran al estado de consistencia que existía antes 
del fallo. Consideremos un programa para transfe¬ 
rir 50 € desde la cuenta A a la B. Si ocurre un fallo 
del sistema durante la ejecución del programa, es 
posible que los 50 € fueron eliminados de la cuen¬ 
ta Apero no abonados a la cuenta B, resultando un 
estado de la base de datos inconsistente. Clara¬ 
mente, es esencial para la consistencia de la base 
de datos que ambos, el abono y el cargo tengan 
lugar, o que ninguno tenga lugar. Es decir, la trans¬ 


ferencia de fondos debe ser atómica: ésta debe ocu¬ 
rrir en ellos por completo o no ocurrir en absoluto. 
Es difícil asegurar esta propiedad en un sistema de 
procesamiento de archivos convencional. 

• Anomalías en el acceso concurrente. Conforme se 
ha ido mejorando el conjunto de ejecución de los 
sistemas y ha sido posible una respuesta en tiempo 
más rápida, muchos sistemas han ido permitiendo a 
múltiples usuarios actualizar los datos simultánea¬ 
mente. En tales sistemas un entorno de interacción 
de actualizaciones concurrentes puede dar lugar a 
datos inconsistentes. Considérese una cuenta ban¬ 
caria A, que contiene 500 €. Si dos clientes retiran 
fondos (por ejemplo 50 € y 100 € respectivamen¬ 
te) de la cuenta A en aproximadamente el mismo 
tiempo, el resultado de las ejecuciones concurrentes 
puede dejar la cuenta en un estado incorrecto (o 
inconsistente). Supongamos que los programas se 
ejecutan para cada retirada y escriben el resultado 
después. Si los dos programas funcionan concu¬ 
rrentemente, pueden leer ambos el valor 500 €, y 
escribir después 450 € y 400 €, respectivamente. 
Dependiendo de cuál escriba el último valor, la cuen¬ 
ta puede contener bien 450 € o bien 400 €, en lugar 
del valor correcto, 350 €. Para protegerse contra esta 
posibilidad, el sistema debe mantener alguna forma 
de supervisión. Sin embargo, ya que se puede acce¬ 
der a los datos desde muchos programas de aplica¬ 
ción diferentes que no han sido previamente coor¬ 
dinados, la supervisión es difícil de proporcionar. 

• Problemas de seguridad. No todos los usuarios de 
un sistema de bases de datos deberían poder acce¬ 
der a todos los datos. Por ejemplo, en un sistema 
bancario, el personal de nóminas necesita ver sólo 
esa parte de la base de datos que tiene información 
acerca de varios empleados del banco. No necesi¬ 
tan acceder a la información acerca de las cuentas 
de clientes. Como los programas de aplicación se 
añaden al sistema de una forma ad hoc, es difícil 
garantizar tales restricciones de seguridad. 

Estas dificultades, entre otras, han motivado el desa¬ 
rrollo de los sistemas de bases de datos. En este libro se 
verán los conceptos y algoritmos que han sido inclui¬ 
dos en los sistemas de bases de datos para resolver los 
problemas mencionados anteriormente. En la mayor 
parte de este libro se usa una empresa bancaria como el 
ejemplo de una aplicación corriente de procesamiento 
de datos típica encontrada en una empresa. 


1.3. VISIÓN DE LOS DATOS 


Un sistema de bases de datos es una colección de archi¬ 
vos interrelacionados y un conjunto de programas que 
permitan a los usuarios acceder y modificar estos archi¬ 
vos. Uno de los propósitos principales de un sistema 


de bases de datos es proporcionar a los usuarios una 
visión abstracta de los datos. Es decir, el sistema escon¬ 
de ciertos detalles de cómo se almacenan y mantienen 
los datos. 
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1.3.1. Abstracción de datos 

Para que el sistema sea útil debe recuperar los datos efi¬ 
cientemente. Esta preocupación ha conducido al dise¬ 
ño de estructuras de datos complejas para la represen¬ 
tación de los datos en la base de datos. Como muchos 
usuarios de sistemas de bases de datos no están fami¬ 
liarizados con computadores, los desarrolladores escon¬ 
den la complejidad a los usuarios a través de varios nive¬ 
les de abstracción para simplificar la interacción de los 
usuarios con el sistema: 

• Nivel físico: El nivel más bajo de abstracción des¬ 
cribe cómo se almacenan realmente los datos. En 
el nivel físico se describen en detalle las estructu¬ 
ras de datos complejas de bajo nivel. 

• Nivel lógico: El siguiente nivel más alto de abs¬ 
tracción describe qué datos se almacenan en la 
base de datos y qué relaciones existen entre esos 
datos. La base de datos completa se describe así 
en términos de un número pequeño de estructu¬ 
ras relativamente simples. Aunque la implemen- 
tación de estructuras simples en el nivel lógico 
puede involucrar estructuras complejas del nivel 
físico, los usuarios del nivel lógico no necesitan 
preocuparse de esta complejidad. Los adminis¬ 
tradores de bases de datos, que deben decidir la 
información que se mantiene en la base de datos, 
usan el nivel lógico de abstracción. 

• Nivel de vistas: El nivel más alto de abstracción 
describe sólo parte de la base de datos completa. 
A pesar del uso de estructuras más simples en el 
nivel lógico, queda algo de complejidad, debido a 
la variedad de información almacenada en una gran 
base de datos. Muchos usuarios del sistema de base 
de datos no necesitan toda esta información. En su 
lugar, tales usuarios necesitan acceder sólo a una 
parte de la base de datos. Para que su interacción 
con el sistema se simplifique, se define la abstrac¬ 
ción del nivel de vistas. El sistema puede propor¬ 
cionar muchas vistas para la misma base de datos. 

La Figura 1.1 muestra la relación entre los tres nive¬ 
les de abstracción. 

Una analogía con el concepto de tipos de datos en 
lenguajes de programación puede clarificar la distin¬ 
ción entre los niveles de abstracción. La mayoría de 
lenguajes de programación de alto nivel soportan la 
estructura de tipo registro. Por ejemplo, en un len¬ 
guaje tipo Pascal, se pueden declarar registros como 
sigue: 

type cliente = record 

nombre-cliente : string; 
id-cliente : string; 
calle-cliente : string; 
ciudad-cliente : string; 
end; 



FIGURA 1.1. Los tres niveles de abstracción de datos. 


Este código define un nuevo registro llamado clien¬ 
te con cuatro campos. Cada campo tiene un nombre y 
un tipo asociado a él. Una empresa bancaria puede tener 
varios tipos de registros, incluyendo 

• cuenta, con campos número-cuenta y saldo 

• empleado, con campos nombre-empleado y sueldo 

En el nivel físico, un registro cliente, cuenta o emplea¬ 
do se puede describir como un bloque de posiciones 
almacenadas consecutivamente (por ejemplo, palabras 
o bytes). El compilador del lenguaje esconde este nivel 
de detalle a los programadores. Análogamente, el sis¬ 
tema de base de datos esconde muchos de los detalles 
de almacenamiento de nivel inferior a los programado- 
res de bases de datos. Los administradores de bases de 
datos pueden ser conscientes de ciertos detalles de la 
organización física de los datos. 

En el nivel lógico cada registro de este tipo se des¬ 
cribe mediante una definición de tipo, como se ha ilus¬ 
trado en el fragmento de código previo, y se define la 
relación entre estos tipos de registros. Los programa- 
dores, cuando usan un lenguaje de programación, tra¬ 
bajan en este nivel de abstracción. De forma similar, los 
administradores de bases de datos trabajan habitual¬ 
mente en este nivel de abstracción. 

Finalmente, en el nivel de vistas, los usuarios de com¬ 
putadores ven un conjunto de programas de aplicación 
que esconden los detalles de los tipos de datos. Análo¬ 
gamente, en el nivel de vistas se definen varias vistas 
de una base de datos y los usuarios de la misma ven úni¬ 
ca y exclusivamente esas vistas. Además de esconder 
detalles del nivel lógico de la base de datos, las vistas 
también proporcionan un mecanismo de seguridad para 
evitar que los usuarios accedan a ciertas partes de la 
base de datos. Por ejemplo, los cajeros de un banco ven 
únicamente la parte de la base de datos que tiene infor¬ 
mación de cuentas de clientes; no pueden acceder a la 
información referente a los sueldos de los empleados. 

1.3.2. Ejemplares y esquemas 

Las bases de datos van cambiando a lo largo del tiem¬ 
po conforme la información se inserta y borra. La colec¬ 
ción de información almacenada en la base de datos en 
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un momento particular se denomina un ejemplar de la 
base de datos. El diseño completo de la base de datos 
se llama el esquema de la base de datos. Los esquemas 
son raramente modificados, si es que lo son alguna vez. 

El concepto de esquemas y ejemplares de bases de 
datos se puede entender por analogía con un programa 
escrito en un lenguaje de programación. Un esquema 
de base de datos corresponde a las declaraciones de 
variables (junto con definiciones de tipos asociadas) 
en un programa. Cada variable tiene un valor particu¬ 
lar en un instante de tiempo. Los valores de las varia¬ 
bles en un programa en un instante de tiempo corres¬ 
ponde a un ejemplar de un esquema de bases de datos. 

Los sistemas de bases de datos tiene varios esquemas 
divididos de acuerdo a los niveles de abstracción que se 
han discutido. El esquema físico describe el diseño físi¬ 
co en el nivel físico, mientras que el esquema lógico des¬ 


cribe el diseño de la base de datos en el nivel lógico. Una 
base de datos puede tener también varios esquemas en 
el nivel de vistas, a menudo denominados subesquemas, 
que describen diferentes vistas de la base de datos. 

De éstos, el esquema lógico es con mucho el más 
importante, en términos de su efecto en los programas 
de aplicación, ya que los programadores construyen las 
aplicaciones usando el esquema lógico. El esquema físi¬ 
co está oculto bajo el esquema lógico, y puede ser fácil¬ 
mente cambiado usualmente sin afectar a los programas 
de aplicación. Los programas de aplicación se dice que 
muestran independencia física de datos si no dependen 
del esquema físico y, por tanto, no deben ser modifica¬ 
dos si cambia el esquema físico. 

Se estudiarán los lenguajes para la descripción de los 
esquemas, después de introducir la noción de modelos 
de datos en el siguiente apartado. 


1.4. MODELOS DE LOS DATOS 


Bajo la estructura de la base de datos se encuentra el 
modelo de datos: una colección de herramientas con¬ 
ceptuales para describir los datos, las relaciones, la 
semántica y las restricciones de consistencia. Para ilus¬ 
trar el concepto de un modelo de datos, describimos dos 
modelos de datos en este apartado: el modelo entidad- 
relación y el modelo relacional. Los diferentes mode¬ 
los de datos que se han propuesto se clasifican en tres 
grupos diferentes: modelos lógicos basados en objetos, 
modelos lógicos basados en registros y modelos físicos. 

1.4.1. Modelo entidad-relación 

El modelo de datos entidad-relación (E-R) está basado 
en una percepción del mundo real que consta de una 
colección de objetos básicos, llamados entidades , y de 
relaciones entre estos objetos. Una entidad es una «cosa» 
u «objeto» en el mundo real que es distinguible de otros 
objetos. Por ejemplo, cada persona es una entidad, y las 
cuentas bancadas pueden ser consideradas entidades. 

Las entidades se describen en una base de datos 
mediante un conjunto de atributos. Por ejemplo, los 
atributos número-cuenta y saldo describen una cuenta 
particular de un banco y pueden ser atributos del con¬ 
junto de entidades cuenta. Análogamente, los atributos 
nombre-cliente, calle-cliente y ciudad-cliente pueden 
describir una entidad cliente. 

Un atributo extra, id-cliente, se usa para identificar 
unívocamente a los clientes (dado que puede ser posi¬ 
ble que haya dos clientes con el mismo nombre, direc¬ 


ción y ciudad. Se debe asignar un identificador único 
de cliente a cada cliente. En los Estados Unidos, muchas 
empresas utilizan el número de la seguridad social de 
una persona (un número único que el Gobierno de los 
Estados Unidos asigna a cada persona en los Estados 
Unidos) como identificador de cliente*. 

Una relación es una asociación entre varias entida¬ 
des. Por ejemplo, una relación impositor asocia un clien¬ 
te con cada cuenta que tiene. El conjunto de todas las 
entidades del mismo tipo, y el conjunto de todas las rela¬ 
ciones del mismo tipo, se denominan respectivamente 
conjunto de entidades y conjunto de relaciones. 

La estructura lógica general de una base de datos se 
puede expresar gráficamente mediante un diagrama E- 
R, que consta de los siguientes componentes: 

• Rectángulos, que representan conjuntos de enti¬ 
dades. 

• Elipses, que representan atributos. 

• Rombos, que representan relaciones entre con¬ 
juntos de entidades. 

• Líneas, que unen los atributos con los conjuntos 
de entidades y los conjuntos de entidades con las 
relaciones. 

Cada componente se etiqueta con la entidad o rela¬ 
ción que representa. 

Como ilustración, considérese parte de una base de 
datos de un sistema bancario consistente en clientes y 
cuentas que tienen esos clientes. En la Figura 1.2 se 


* N. del T. En España, muchas empresas usan el D.N.l. como identi¬ 
ficador unívoco, pero a veces encuentran problemas con los núme¬ 
ros de D.N.l. que por desgracia aparecen repetidos. Para resolverlo, 
o bien se usa otro identificador propio de la empresa o se añade un 
código al número de D.N.l. 
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FIGURA 1.2. Ejemplo de diagrama E-R. 


muestra el diagrama E-R correspondiente. El diagrama 
E-R indica que hay dos conjuntos de entidades cliente 
y cuenta, con los atributos descritos anteriormente. El 
diagrama también muestra la relación impositor entre 
cliente y cuenta. 

Además de entidades y relaciones, el modelo E-R 
representa ciertas restricciones que los contenidos de la 
base de datos deben cumplir. Una restricción importante 
es la correspondencia de cardinalidades, que expresa 
el número de entidades con las que otra entidad se pue¬ 
de asociar a través de un conjunto de relaciones. Por 
ejemplo, si cada cuenta puede pertenecer sólo a un clien¬ 
te, el modelo puede expresar esta restricción. 

El modelo entidad-relación se utiliza habitualmente 
en el proceso de diseño de bases de datos, y se estudia¬ 
rá en produndidad en el Capítulo 2. 

1.4.2. Modelo relacional 

En el modelo relacional se utiliza un grupo de tablas 
para representar los datos y las relaciones entre ellos. 
Cada tabla está compuesta por varias columnas, y cada 
columna tiene un nombre único. En la Figura 1.3 se pre¬ 
senta un ejemplo de base de datos relacional consisten¬ 
te en tres tablas: la primera muestra los clientes de un 
banco, la segunda, las cuentas, y la tercera, las cuentas 
que pertenecen a cada cliente. 


id-cliente 

nombre-cliente 

calle-cliente 

ciudad-cliente 

19.283.746 

01.928.374 

67.789.901 

18.273.609 

32.112.312 

33.666.999 

01.928.374 

González 

Gómez 

López 

Abril 

Santos 

Rupérez 

Gómez 

Arenal 

Carretas 

Mayor 

Preciados 

Mayor 

Ramblas 

Carretas 

La Granja 

Cerceda 

Peguerinos 

Valsaín 

Peguerinos 

León 

Cerceda 


(a) La tabla cliente 


FIGURA 1.3. Ejemplo de base de datos relacional. 


La primera tabla, la tabla cliente, muestra, por ejem¬ 
plo, que el cliente cuyo identificador es 19.283.746 se lla¬ 
ma González y vive en la calle Arenal sita en La Granja. 
La segunda tabla, cuenta, muestra que las cuentas C-101 
tienen un saldo de 500 € y la C-201 un saldo de 900 € 
respectivamente. 

La tercera tabla muestra las cuentas que pertenecen 
a cada cliente. Por ejemplo, la cuenta C-101 pertenece 
al cliente cuyo identificador es 19.283.746 (González), 
y los clientes 19.283.746 (González) y 01.928.374 
(Gómez) comparten el número de cuenta A-201 (pue¬ 
den compartir un negocio). 

El modelo relacional es un ejemplo de un modelo 
basado en registros. Los modelos basados en registros 
se denominan así porque la base de datos se estructura 
en registros de formato fijo de varios tipos. Cada tabla 
contiene registros de un tipo particular. Cada tipo de 
registro define un número fijo de campos, o atributos. 
Las columnas de la tabla corresponden a los atributos 
del tipo de registro. 

No es difícil ver cómo se pueden almacenar las tablas 
en archivos. Por ejemplo, un carácter especial (como 
una coma) se puede usar para delimitar los diferentes 
atributos de un registro, y otro carácter especial (como 
un carácter de nueva línea) se puede usar para delimitar 
registros. El modelo relacional oculta tales detalles de 
implementación de bajo nivel a los desarrolladores de 
bases de datos y usuarios. 

El modelo de datos relacional es el modelo de datos 
más ampliamente usado, y una amplia mayoría de sis¬ 
temas de bases de datos actuales se basan en el mode¬ 
lo relacional. Los Capítulos 3 a 7 tratan el modelo rela¬ 
cional en detalle. 

El modelo relacional se encuentra a un nivel de abs¬ 
tracción inferior al modelo de datos E-R. Los diseños 
de bases de datos a menudo se realizan en el modelo 
E-R, y después se traducen al modelo relacional; el Capí¬ 
tulo 2 describe el proceso de traducción. Por ejemplo, 
es fácil ver que las tablas cliente y cuenta corresponden 
a los conjuntos de entidades del mismo nombre, mien¬ 
tras que la tabla impositor corresponde al conjunto de 
relaciones impositor. 

Nótese también que es posible crear esquemas en el 
modelo relacional que tengan problemas tales como infor¬ 
mación duplicada innecesariamente. Por ejemplo, supon¬ 
gamos que se almacena número-cuenta como un atribu¬ 
to del registro cliente. Entonces, para representar el hecho 
de que las cuentas C-101 y C-201 pertenecen ambas al 
cliente González (con identificador de cliente 19.283.746) 
sería necesario almacenar dos filas en la tabla cliente. 
Los valores de nombre-cliente, calle-cliente y ciudad- 
cliente de González estarían innecesariamente duplica¬ 
dos en las dos filas. En el Capítulo 7 se estudiará cómo 
distinguir buenos diseños de esquema de malos diseños. 

1.4.3. Otros modelos de datos 

El modelo de datos orientado a objetos es otro mode¬ 
lo de datos que está recibiendo una atención creciente. 


id-cliente 

número-cuenta 

19.283.746 

C-101 

19.283.746 

C-201 

01.928.374 

C-215 

67.789.901 

C-102 

18.273.609 

C-305 

32.112.312 

C-217 

33.666.999 

C-222 

01.928.374 

C-201 


(b) La tabla impositor 


número-cuenta 

saldo 

C-101 

500 

C-215 

700 

C-102 

400 

C-305 

350 

C-201 

900 

C-217 

750 

C-222 

700 


(b) La tabla cuenta 
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El modelo orientado a objetos se puede observar como 
una extensión del modelo E-R con las nociones de 
encapsulación, métodos (funciones) e identidad de obje¬ 
to. El Capítulo 8 examina el modelo de datos orienta¬ 
do a objetos. 

El modelo de datos relacional orientado a objetos 

combina las características del modelo de datos orien¬ 
tado a objetos y el modelo de datos relacional. El Capí¬ 
tulo 9 lo examina. 

Los modelos de datos semiestructurados permiten la 
especificación de datos donde los elementos de datos 
individuales del mismo tipo pueden tener diferentes con¬ 
juntos de atributos. Esto es diferente de los modelos de 
datos mencionados anteriormente, en los que cada ele¬ 


mento de datos de un tipo particular debe tener el mis¬ 
mo conjunto de atributos. El lenguaje de marcas exten- 
sible (XML, eXtensible Markup Language) se usa 
ampliamente para representar datos semiestructurados. 
El Capítulo 10 lo trata. 

Históricamente, otros dos modelos de datos, el mode¬ 
lo de datos de red y el modelo de datos jerárquico, 

precedieron al modelo de datos relacional. Estos mode¬ 
los estuvieron ligados fuertemente a la implementación 
subyacente y complicaban la tarea del modelado de 
datos. Como resultado se usan muy poco actualmente, 
excepto en el código de bases de datos antiguo que aún 
está en servicio en algunos lugares. Se describen en los 
apéndices A y B para los lectores interesados. 


1.5. LENGUAJES DE BASES DE DATOS 


Un sistema de bases de datos proporciona un lenguaje de 
definición de datos para especificar el esquema de la base 
de datos y un lenguaje de manipulación de datos para 
expresar las consultas a la base de datos y las modifica¬ 
ciones. En la práctica, los lenguajes de definición y mani¬ 
pulación de datos no son dos lenguajes separados; en su 
lugar simplemente forman partes de un único lenguaje de 
bases de datos, tal como SQL, ampliamente usado. 

1.5.1. Lenguaje de definición de datos 

Un esquema de base de datos se especifica mediante un 
conjunto de definiciones expresadas mediante un len¬ 
guaje especial llamado lenguaje de definición de datos 
(LDD). 

Por ejemplo, la siguiente instrucción en el lenguaje 
SQL define la tabla cuenta. 

create table cuenta 

(número-cuenta char(10), 
saldo integer) 

La ejecución de la instrucción LDD anterior crea la 
tabla cuenta. Además, actualiza un conjunto especial de 
tablas denominado diccionario de datos o directorio 
de datos. 

Un diccionario de datos contiene metadatos, es decir, 
datos acerca de los datos. El esquema de una tabla es 
un ejemplo de metadatos. Un sistema de base de datos 
consulta el diccionario de datos antes de leer o modifi¬ 
car los datos reales. 

Especificamos el almacenamiento y los métodos de 
acceso usados por el sistema de bases de datos por un 
conjunto de instrucciones en un tipo especial de LDD 
denominado lenguaje de almacenamiento y definición 
de datos. Estas instrucciones definen los detalles de 
implementación de los esquemas de base de datos, que 
se ocultan usualmente a los usuarios. 


Los valores de datos almacenados en la base de datos 
deben satisfacer ciertas restricciones de consistencia. 
Por ejemplo, supóngase que el saldo de una cuenta no 
debe caer por debajo de 100 €. El LDD proporciona 
facilidades para especificar tales restricciones. Los sis¬ 
temas de bases de datos comprueban estas restricciones 
cada vez que se actualiza la base de datos. 

1.5.2. Lenguaje de manipulación de datos 
La manipulación de datos es: 

• La recuperación de información almacenada en la 
base de datos. 

• La inserción de información nueva en la base de 
datos. 

• El borrado de información de la base de datos. 

• La modificación de información almacenada en la 
base de datos. 

Un lenguaje de manipulación de datos (LMD) es 
un lenguaje que permite a los usuarios acceder o mani¬ 
pular los datos organizados mediante el modelo de datos 
apropiado. Hay dos tipos básicamente: 

• LMDs procedimentales. Requieren que el usua¬ 
rio especifique qué datos se necesitan y cómo obte¬ 
ner esos datos. 

• LMDs declarativos (también conocidos como 
LMDs no procedimentales). Requieren que el 
usuario especifique qué datos se necesitan sin espe¬ 
cificar cómo obtener esos datos. 

Los LMDs declarativos son más fáciles de aprender 
y usar que los LMDs procedimentales. Sin embargo, 
como el usuario no especifica cómo conseguir los datos, 
el sistema de bases de datos tiene que determinar un 
medio eficiente de acceder a los datos. El componente 
LMD del lenguaje SQL es no procedimental. 
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Una consulta es una instrucción de solicitud para recu¬ 
perar información. La parte de un LMD que implica recu¬ 
peración de información se llama lenguaje de consul¬ 
tas. Aunque técnicamente sea incorrecto, en la práctica 
se usan los términos lenguaje de consultas y lenguaje de 
manipulación de datos como sinónimos. 

Esta consulta en el lenguaje SQL encuentra el nom¬ 
bre del cliente cuyo identiñcador de cliente es 19.283.746: 

select cliente.nombre-cliente 
from cliente 

where cliente.id-cliente = ‘19 283 746’ 

La consulta especifica que las filas de (from) la tabla 
cliente donde (where) el id-cliente es 19 283 746 se debe 
recuperar, y que se debe mostrar el atributo nombre- 
cliente de estas filas. Si se ejecutase la consulta con la 
tabla de la Figura 1.3, se mostraría el nombre González. 

Las consultas pueden involucrar información de más 
de una tabla. Por ejemplo, la siguiente consulta encuen¬ 
tra el saldo de todas las cuentas pertenecientes al clien¬ 
te cuyo identiñcador de cliente es 19 283 746. 

select cuenta.saldo 
from impositor, cuenta 

where impositor .id-cliente = ‘19-283-746’ and 
impositor.número-cuenta = cuenta.número- 
cuenta 

Si la consulta anterior se ejecutase con las tablas de 
la Figura 1.3, el sistema encontraría que las dos cuen¬ 
tas denominadas C-101 y C-201 pertenecen al cliente 
19 283 746 e imprimiría los saldos de las dos cuentas, 
es decir, 500 y 900 €. 

Hay varios lenguajes de consulta de bases de datos 
en uso, ya sea comercialmente o experimentalmente. Se 
estudiará el lenguaje de consultas más ampliamente usa¬ 
do, SQL, en el Capítulo 4. También se estudiarán otros 
lenguajes de consultas en el Capítulo 5. 

Los niveles de abstracción que se discutieron en el 
Apartado 1.3 se aplican no solo a la definición o estruc¬ 
turación de datos, sino también a la manipulación de datos. 


En el nivel físico se deben definir algoritmos que permi¬ 
tan un acceso eficiente a los datos. En los niveles supe¬ 
riores de abstracción se enfatiza la facilidad de uso. El 
objetivo es proporcionar una interacción humana eficiente 
con el sistema. El componente procesador de consultas 
del sistema de bases de datos (que se estudia en los Capí¬ 
tulos 13 y 14) traduce las consultas LMD en secuencias 
de acciones en el nivel físico del sistema de bases de datos. 

1.5.3. Acceso a la base de datos 

desde programas de aplicación 

Los programas de aplicación son programas que se usan 
para interaccionar con la base de datos. Los programas 
de aplicación se escriben usualmente en un lenguaje anfi¬ 
trión ,, tal como Cobol, C, C++ o Java. En el sistema ban- 
cario algunos ejemplos son programas que emiten los che¬ 
ques de las nóminas, las cuentas de débito, las cuentas de 
crédito o las transferencias de fondos entre cuentas. 

Para acceder a la base de datos, las instrucciones 
LMD necesitan ser ejecutadas desde el lenguaje anfi¬ 
trión. Hay dos maneras de hacerlo: 

• Proporcionando una interfaz de programas de apli¬ 
cación (conjunto de procedimientos) que se pue¬ 
den usar para enviar instrucciones LMD y LDD a 
la base de datos, y recuperar los resultados. 

El estándar de conectividad abierta de bases de 
datos (ODBC, Open Data Base Connectivity) defi¬ 
nido por Microsoft para el uso con el lenguaje C 
es un estándar de interfaz de programas de apli¬ 
cación usado comúnmente. El estándar conectivi¬ 
dad de Java con bases de datos (JDBC, Java Data 
Base Connectivity) proporciona características 
correspondientes para el lenguaje Java. 

• Extendiendo la sintaxis del lenguaje anfitrión para 
incorporar llamadas LMD dentro del programa del 
lenguaje anfitrión. Usualmente, un carácter espe¬ 
cial precede a las llamadas LMD, y un preproce¬ 
sador, denominado el precompilador LMD, con¬ 
vierte las instrucciones LMD en llamadas normales 
a procedimientos en el lenguaje anfitrión. 


1.6. USUARIOS Y ADMINISTRADORES DE LA BASE DE DATOS 


Un objetivo principal de un sistema de bases de datos es 
recuperar información y almacenar nueva información 
en la base de datos. Las personas que trabajan con una 
base de datos se pueden catalogar como usuarios de bases 
de datos o como administradores de bases de datos. 

1.6.1. Usuarios de bases de datos e interfaces 
de usuario 

Hay cuatro tipos diferentes de usuarios de un sistema 
de base de datos, diferenciados por la forma en que ellos 


esperan interactuar con el sistema. Se han diseñado dife¬ 
rentes tipo de interfaces de usuario para diferentes tipos 
de usuarios. 

• Usuarios normales. Son usuarios no sofisticados 
que interactúan con el sistema mediante la invo¬ 
cación de alguno de los programas de aplicación 
permanentes que se ha escrito previamente. Por 
ejemplo, un cajero bancario que necesita transfe¬ 
rir 50 € de la cuenta A a la cuenta B invoca un pro¬ 
grama llamado transferir. Este programa pide al 
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cajero el importe de dinero a transferir, la cuenta 
de la que el dinero va a ser transferido y la cuenta 
a la que el dinero va a ser transferido. 

Como otro ejemplo, considérese un usuario que 
desee encontrar su saldo de cuenta en World Wide 
Web. Tal usuario podría acceder a un formulario 
en el que introduce su número de cuenta. Un pro¬ 
grama de aplicación en el servidor Web recupera 
entonces el saldo de la cuenta, usando el número 
de cuenta proporcionado, y pasa la información al 
usuario. 

La interfaz de usuario normal para los usuarios 
normales es una interfaz de formularios, donde el 
usuario puede rellenar los campos apropiados del 
formulario. Los usuarios normales pueden tam¬ 
bién simplemente leer informes generados de la 
base de datos. 

• Programadores de aplicaciones. Son profesio¬ 
nales informáticos que escriben programas de apli¬ 
cación. Los programadores de aplicaciones pue¬ 
den elegir entre muchas herramientas para 
desarrollar interfaces de usuario. Las herramien¬ 
tas de desarrollo rápido de aplicaciones (DRA) 
son herramientas que permiten al programador de 
aplicaciones construir formularios e informes sin 
escribir un programa. Hay también tipos especia¬ 
les de lenguajes de programación que combinan 
estructuras de control imperativo (por ejemplo, 
para bucles for, bucles while e instrucciones if- 
then-else) con instrucciones del lenguaje de mani¬ 
pulación de datos. Estos lenguajes, llamados a 
veces lenguajes de cuarta generación, a menudo 
incluyen características especiales para facilitar la 
generación de formularios y la presentación de 
datos en pantalla. La mayoría de los sistemas de 
bases de datos comerciales incluyen un lenguaje 
de cuarta generación. 

• Los usuarios sofisticados interactúan con el sis¬ 
tema sin programas escritos. En su lugar, ellos for¬ 
man sus consultas en un lenguaje de consulta de 
bases de datos. Cada una de estas consultas se envía 
al procesador de consultas, cuya función es trans¬ 
formar instrucciones LMD a instrucciones que el 
gestor de almacenamiento entienda. Los analistas 
que envían las consultas para explorar los datos en 
la base de datos entran en esta categoría. 

Las herramientas de procesamiento analítico 
en línea (OLAP, Online Analytical Processing) 
simplifican la labor de los analistas permitiéndo¬ 
les ver resúmenes de datos de formas diferentes. 
Por ejemplo, un analista puede ver las ventas tota¬ 
les por región (por ejemplo, norte, sur, este y oes¬ 
te), o por producto, o por una combinación de la 
región y del producto (es decir, las ventas totales 
de cada producto en cada región). Las herramien¬ 
tas también permiten al analista seleccionar regio¬ 
nes específicas, examinar los datos con más deta¬ 


lle (por ejemplo, ventas por ciudad dentro de una 
región) o examinar los datos con menos detalle 
(por ejemplo, agrupando productos por categoría). 

Otra clase de herramientas para los analistas 
son las herramientas de recopilación de datos, que 
les ayudan a encontrar ciertas clases de patrones 
de datos. 

En el Capítulo 22 se estudiarán las herramien¬ 
tas de recopilación de datos. 

• Usuarios especializados. Son usuarios sofistica¬ 
dos que escriben aplicaciones de bases de datos 
especializadas que no son adecuadas en el marco 
de procesamiento de datos tradicional. Entre estas 
aplicaciones están los sistemas de diseño asistido 
por computador, sistemas de bases de conoci¬ 
mientos y sistemas expertos, sistemas que alma¬ 
cenan los datos con tipos de datos complejos (por 
ejemplo, datos gráficos y datos de audio) y siste¬ 
mas de modelado del entorno. Varias de estas apli¬ 
caciones se tratan en los Capítulos 8 y 9. 

1.6.2. Administrador de la base de datos 

Una de las principales razones de usar SGBDs es tener 
un control centralizado tanto de los datos como de los 
programas que acceden a esos datos. La persona que 
tiene este control central sobre el sistema se llama admi¬ 
nistrador de la base de datos (ABD). Las funciones 
del ABD incluyen las siguientes: 

• Definición del esquema. El ABD crea el esque¬ 
ma original de la base de datos escribiendo un con¬ 
junto de instrucciones de definición de datos en el 
LDD. 

• Definición de la estructura y del método de ac¬ 
ceso. 

• Modificación del esquema y de la organización 
física. Los ABD realizan cambios en el esquema 
y en la organización física para reflejar las necesi¬ 
dades cambiantes de la organización, o para alte¬ 
rar la organización física para mejorar el rendi¬ 
miento. 

• Concesión de autorización para el acceso a los 
datos. La concesión de diferentes tipos de autori¬ 
zación permite al administrador de la base de datos 
determinar a qué partes de la base de datos puede 
acceder cada usuario. La información de autoriza¬ 
ción se mantiene en una estructura del sistema espe¬ 
cial que el sistema de base de datos consulta cuan¬ 
do se intenta el acceso a los datos en el sistema. 

• Mantenimiento rutinario. Algunos ejemplos de 
actividades rutinarias de mantenimiento del admi¬ 
nistrado de la base de datos son: 

— Copia de seguridad periódica de la base de 
datos, bien sobre cinta o sobre servidores remo¬ 
tos, para prevenir la pérdida de datos en caso 
de desastres como inundaciones. 
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Asegurarse de que haya suficiente espacio libre 
en disco para las operaciones normales y 
aumentar el espacio en disco según sea nece¬ 
sario. 


Supervisión de los trabajos que se ejecuten en la 
base de datos y asegurarse de que el rendimiento 
no se degrada por tareas muy costosas iniciadas 
por algunos usuarios. 


1.7. GESTIÓN DE TRANSACCIONES 


Varias operaciones sobre la base de datos forman a 
menudo una única unidad lógica de trabajo. Un ejem¬ 
plo que se vio en el Apartado 1.2 es la transferencia de 
fondos, en el que una cuenta (A) se carga y otra cuenta 
( B ) se abona. Claramente es esencial que, o bien tanto 
el cargo como el abono tengan lugar, o bien no ocurra 
ninguno. Es decir, la transferencia de fondos debe ocu¬ 
rrir por completo o no ocurrir en absoluto. Este requisito 
de todo o nada se denomina atomicidad. Además, es 
esencial que la ejecución de la transferencia de fondos 
preserve la consistencia de la base de datos. Es decir, el 
valor de la suma A + B se debe preservar. Este requisi¬ 
to de corrección se llama consistencia. Finalmente, tras 
la ejecución correcta de la transferencia de fondos, los 
nuevos valores de las cuentas Ay B deben persistir, a 
pesar de la posibilidad de fallo del sistema. Este requi¬ 
sito de persistencia se llama durabilidad. 

Una transacción es una colección de operaciones 
que se lleva a cabo como una única función lógica en 
una aplicación de bases de datos. Cada transacción es 
una unidad de atomicidad y consistencia. Así, se requie¬ 
re que las transacciones no violen ninguna restricción 
de consistencia de la base de datos. Es decir, si la base 
de datos era consistente cuando la transacción comen¬ 
zó, la base de datos debe ser consistente cuando la tran¬ 
sacción termine con éxito. Sin embargo, durante la eje¬ 
cución de una transacción, puede ser necesario permitir 
inconsistencias temporalmente, ya que o el cargo de A 
o el abono de B se debe realizar uno antes que otro. Esta 
inconsistencia temporal, aunque necesaria, puede con¬ 
ducir a dificultades si ocurre un fallo. 

Es responsabilidad del programador definir adecua¬ 
damente las diferentes transacciones, de tal manera que 
cada una preserve la consistencia de la base de datos. 
Por ejemplo, la transacción para transferir fondos de la 
cuenta A a la cuenta B se podría definir como compuesta 
de dos programas separados: uno que carga la cuenta A 
y otro que abona la cuenta B. La ejecución de estos dos 
programas uno después del otro preservará realmente 


la consistencia. Sin embargo, cada programa en sí mis¬ 
mo no transforma la base de datos de un estado consis¬ 
tente en otro nuevo estado consistente. Así, estos pro¬ 
gramas no son transacciones. 

Asegurar las propiedades de atomicidad y durabili¬ 
dad es responsabilidad del propio sistema de bases de 
datos, específicamente del componente de gestión de 
transacciones. En ausencia de fallos, toda transacción 
completada con éxito y atómica se archiva fácilmente. 
Sin embargo, debido a diversos tipos de fallos, una tran¬ 
sacción puede no siempre completar su ejecución con 
éxito. Si se asegura la propiedad de atomicidad, una tran¬ 
sacción que falle no debe tener efecto en el estado de la 
base de datos. Así, la base de datos se restaura al esta¬ 
do en que estaba antes de que la transacción en cuestión 
comenzara su ejecución. El sistema de bases de datos 
debe realizar la recuperación de fallos, es decir, detec¬ 
tar los fallos del sistema y restaurar la base de datos al 
estado que existía antes de que ocurriera el fallo. 

Finalmente, cuando varias transacciones actualizan 
la base de datos concurrentemente, la consistencia de 
los datos puede no ser preservada, incluso aunque cada 
transacción individualmente sea correcta. Es responsa¬ 
bilidad del gestor de control de concurrencia contro¬ 
lar la interacción entre las transacciones concurrentes 
para asegurar la consistencia de la base de datos. 

Los sistemas de bases de datos diseñados para uso 
sobre pequeños computadores personales pueden no 
tener todas las características vistas. Por ejemplo, muchos 
sistemas pequeños imponen la restricción de permitir el 
acceso a un único usuario a la base de datos en un ins¬ 
tante de tiempo. Otros dejan las tareas de copias de segu¬ 
ridad y recuperación a los usuarios. Estas restricciones 
permiten un gestor de datos más pequeño, con menos 
requisitos de recursos físicos, especialmente de memo¬ 
ria principal. Aunque tales enfoques de bajo coste y pres¬ 
taciones son suficientes para bases de datos personales 
pequeñas, son inadecuadas para satisfacer las necesida¬ 
des de una empresa de media a gran escala. 


1.8. ESTRUCTURA DE UN SISTEMA DE BASES DE DATOS 


Un sistema de bases de datos se divide en módulos que 
se encargan de cada una de las responsabilidades del sis¬ 
tema completo. Los componentes funcionales de un 
sistema de bases de datos se pueden dividir a grandes 


rasgos en los componentes gestor de almacenamiento 
y procesador de consultas. 

El gestor de consultas es importante porque las bases 
de datos requieren normalmente una gran cantidad de 
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espacio de almacenamiento. Las bases de datos corpo¬ 
rativas tienen un tamaño de entre cientos de gigabytes 
y, para las mayores bases de datos, terabytes de datos. 
Un gigabyte son 1.000 megabytes (1.000 millones de 
bytes), y un terabyte es 1 millón de megabytes (1 billón 
de bytes). Debido a que la memoria principal de los 
computadores no puede almacenar esta gran cantidad 
de información, esta se almacena en discos. Los datos 
se trasladan entre el disco de almacenamiento y la 
memoria principal cuando es necesario. Como la trans¬ 
ferencia de datos a y desde el disco es lenta compara¬ 
da con la velocidad de la unidad central de procesa¬ 
miento, es fundamental que el sistema de base de datos 
estructure los datos para minimizar la necesidad de 
movimiento de datos entre el disco y la memoria prin¬ 
cipal. 

El procesador de consultas es importante porque ayu¬ 
da al sistema de bases de datos a simplificar y facilitar 
el acceso a los datos. Las vistas de alto nivel ayudan a 
conseguir este objetivo. Con ellas, los usuarios del sis¬ 
tema no deberían ser molestados innecesariamente con 
los detalles físicos de implementación del sistema. Sin 
embargo, el rápido procesamiento de las actualizacio¬ 
nes y de las consultas es importante. Es trabajo del sis¬ 
tema de bases de datos traducir las actualizaciones y las 
consultas escritas en un lenguaje no procedimental, en 
el nivel lógico, en una secuencia de operaciones en el 
nivel físico. 

1.8.1. Gestor de almacenamiento 

Un gestor de almacenamiento es un módulo de pro¬ 
grama que proporciona la interfaz entre los datos de bajo 
nivel en la base de datos y los programas de aplicación 
y consultas emitidas al sistema. El gestor de almacena¬ 
miento es responsable de la interacción con el gestor de 
archivos. Los datos en bruto se almacenan en disco usan¬ 
do un sistema de archivos, que está disponible ha¬ 
bitualmente en un sistema operativo convencional. El 
gestor de almacenamiento traduce las diferentes ins¬ 
trucciones LMD a órdenes de un sistema de archivos 
de bajo nivel. Así, el gestor de almacenamiento es res¬ 
ponsable del almacenamiento, recuperación y actuali¬ 
zación de los datos en la base de datos. 

Los componentes del gestor de almacenamiento 
incluyen: 

• Gestor de autorización e integridad, que com¬ 
prueba que se satisfagan las restricciones de inte¬ 
gridad y la autorización de los usuarios para acce¬ 
der a los datos. 

• Gestor de transacciones, que asegura que la base 
de datos quede en un estado consistente (correc¬ 


to) a pesar de los fallos del sistema, y que las eje¬ 
cuciones de transacciones concurrentes ocurran si 
conflictos. 

• Gestor de archivos, que gestiona la reserva de 
espacio de almacenamiento de disco y las estruc¬ 
turas de datos usadas para representar la informa¬ 
ción almacenada en disco. 

• Gestor de memoria intermedia, que es respon¬ 
sable de traer los datos del disco de almacena¬ 
miento a memoria principal y decidir qué datos 
tratar en memoria caché. El gestor de memoria 
intermedia es una parte crítica del sistema de bases 
de datos, ya que permite que la base de datos mane¬ 
je tamaños de datos que son mucho mayores que 
el tamaño de la memoria principal. 

El gestor de almacenamiento implementa varias 
estructuras de datos como parte de la implementación 
física del sistema: 

• Archivos de datos, que almacenan la base de datos 
en sí. 

• Diccionario de datos, que almacena metadatos 
acerca de la estructura de la base de datos, en par¬ 
ticular, el esquema de la base de datos. 

• índices, que proporcionan acceso rápido a ele¬ 
mentos de datos que tienen valores particulares. 

1.8.2. Procesador de consultas 

Los componentes del procesador de consultas incluyen: 

• Intérprete del LDD, que interpreta las instruc¬ 
ciones del LDD y registra las definiciones en el 
diccionario de datos. 

• Compilador del LMD, que traduce las instruc¬ 
ciones del LMD en un lenguaje de consultas a un 
plan de evaluación que consiste en instrucciones 
de bajo nivel que entiende el motor de evaluación 
de consultas. 

Una consulta se puede traducir habitualmente 
en varios planes de ejecución alternativos que pro¬ 
porcionan el mismo resultado. El compilador del 
LMD también realiza optimización de consultas, 
es decir, elige el plan de evaluación de menor cos¬ 
te de entre todas las alternativas. 

• Motor de evaluación de consultas, que ejecuta 
las instrucciones de bajo nivel generadas por el 
compilador del LMD. 

En la Figura 1.4 se muestran estos componentes y 
sus conexiones. 
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FIGURA 1.4. Estructura del sistema. 


1.9. ARQUITECTURAS DE APLICACIONES 


La mayoría de usuarios de un sistema de bases de datos 
no están situados actualmente junto al sistema de bases 
de datos, sino que se conectan a él a través de una red. 
Se puede diferenciar entonces entre las máquinas clien¬ 
te, en donde trabajan los usuarios remotos de la base de 
datos, y las máquinas servidor, en las que se ejecuta el 
sistema de bases de datos. 

Las aplicaciones de bases de datos se dividen usual¬ 
mente en dos o tres partes, como se ilustra en la Figu¬ 
ra 1.5. En una arquitectura de dos capas, la aplica¬ 
ción se divide en un componente que reside en la 
máquina cliente, que llama a la funcionalidad del sis¬ 
tema de bases de datos en la máquina servidor median¬ 
te instrucciones del lenguaje de consultas. Los están¬ 
dares de interfaces de programas de aplicación como 


ODBC y JDBC se usan para la interacción entre el 
cliente y el servidor. 

En cambio, en una arquitectura de tres capas, la 
máquina cliente actúa simplemente como frontal y no 
contiene ninguna llamada directa a la base de datos. En 
su lugar, el cliente se comunica con un servidor de apli¬ 
caciones, usualmente mediante una interfaz de formula¬ 
rios. El servidor de aplicaciones, a su vez, se comunica 
con el sistema de bases de datos para acceder a los datos. 
La lógica de negocio de la aplicación, que establece las 
acciones a realizar bajo determinadas condiciones, se 
incorpora en el servidor de aplicaciones, en lugar de ser 
distribuida a múltiples clientes. Las aplicaciones de tres 
capas son más apropiadas para grandes aplicaciones, y 
para las aplicaciones que se ejecutan en World Wide Web. 


12 














































































CAPÍTULO 1 INTRODUCCIÓN 



cliente 


servidor 



a. arquitectura de dos capas 
FIGURA 1.5. Arquitecturas de dos y tres capas. 


b. arquitectura de tres capas 


1.10. HISTORIA DE LOS SISTEMAS DE BASES DE DATOS 


El procesamiento de datos impulsa el crecimiento de 
los computadores, como ocurriera en los primeros días 
de los computadores comerciales. De hecho, la auto¬ 
matización de las tareas de procesamiento de datos pre¬ 
cede a los computadores. Las tarjetas perforadas, in¬ 
ventadas por Hollerith, se usaron en los principios del 
siglo xx para registrar los datos del censo de los EE.UU., 
y se usaron sistemas mecánicos para procesar las tarje¬ 
tas y para tabular los resultados. Las tarjetas perforadas 
posteriormente se usaron ampliamente como medio para 
introducir datos en los computadores. 

Las técnicas del almacenamiento de datos han evo¬ 
lucionado a lo largo de los años: 

• Década de 1950 y principios de la década de 1960. 

Se desarrollaron las cintas magnéticas para el alma¬ 
cenamiento de datos. Las tareas de procesamiento 
de datos tales como las nóminas fueron automati¬ 
zadas, con los datos almacenados en cintas. El pro¬ 
cesamiento de datos consistía en leer datos de una 
o más cintas y escribir datos en una nueva cinta. Los 
datos también se podían introducir desde paquetes 
de tarjetas perforadas e impresos en impresoras. Por 
ejemplo, los aumentos de sueldo se procesaban 
introduciendo los aumentos en las tarjetas perfora¬ 
das y leyendo el paquete de cintas perforadas en sin¬ 
cronización con una cinta que contenía los detalles 
maestros de los salarios. Los registros debían estar 
igualmente ordenados. Los aumentos de sueldo tení¬ 
an que añadirse a los sueldos leídos de la cinta maes¬ 
tra, y escribirse en una nueva cinta; esta nueva cin¬ 
ta se convertía en la nueva cinta maestra. 

Las cintas (y los paquetes de tarjetas perfora¬ 
das) sólo se podían leer secuencialmente, y los 
tamaños de datos eran mucho mayores que la 


memoria principal; así, los programas de procesa¬ 
miento de datos tenían que procesar los datos según 
un determinado orden, leyendo y mezclando datos 
de cintas y paquetes de tarjetas perforadas. 

• Finales de la década de 1960 y la década de 
1970. El amplio uso de los discos fijos a finales de 
la década de 1960 cambió en gran medida el esce¬ 
nario del procesamiento de datos, ya que los dis¬ 
cos fijos permitieron el acceso directo a los datos. 
La ubicación de los datos en disco no era impor¬ 
tante, ya que a cualquier posición del disco se podía 
acceder en sólo decenas de milisegundo. Los datos 
se liberaron de la tiranía de la secuencialidad. Con 
los discos pudieron desarrollarse las bases de datos 
de red y jerárquicas, que permitieron que las estruc¬ 
turas de datos tales como listas y árboles pudieran 
almacenarse en disco. Los programadores pudie¬ 
ron construir y manipular estas estructuras de datos. 

Un artículo histórico de Codd [1970] definió el 
modelo relacional y formas no procedimentales de 
consultar los datos en el modelo relacional, y nacie¬ 
ron las bases de datos relaciónales. La simplicidad 
del modelo relacional y la posibilidad de ocultar 
completamente los detalles de implementación al 
programador fueron realmente atractivas. Codd 
obtuvo posteriormente el prestigioso premio Turing 
de la ACM (Association of Computing Machinery, 
asociación de maquinaria informática) por su tra¬ 
bajo. 

• Década de 1980. Aunque académicamente inte¬ 
resante, el modelo relacional no se usó inicialmente 
en la práctica debido a sus inconvenientes por el 
rendimiento; las bases de datos relaciónales no 
pudieron competir con el rendimiento de las bases 
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de datos de red y jerárquicas existentes. Esta situa¬ 
ción cambió con System R, un proyecto innova¬ 
dor en IBM Research que desarrolló técnicas para 
la construcción de un sistema de bases de datos 
relaciónales eficiente. En Astrahan et al. [1976] y 
Chamberlin et al. [1981] se pueden encontrar exce¬ 
lentes visiones generales de System R. El prototi¬ 
po de System R completamente funcional condu¬ 
jo al primer producto de bases de datos relaciónales 
de IBM: SQL/DS. Los primeros sistemas de bases 
de datos relaciónales, como DB2 de IBM, Oracle, 
Ingres y Rdb de DEC, jugaron un importante papel 
en el desarrollo de técnicas para el procesamiento 
eficiente de consultas declarativas. En los princi¬ 
pios de la década de 1980 las bases de datos rela¬ 
ciónales llegaron a competir con los sistemas de 
bases de datos jerárquicas y de red incluso en el 
área de rendimiento. Las bases de datos relació¬ 
nales fueron tan sencillas de usar que finalmente 
reemplazaron a las bases de datos jerárquicas y de 
red; los programadores que usaban estas bases de 
datos estaban forzados a tratar muchos detalles de 
implementación de bajo nivel y tenían que codifi¬ 
car sus consultas de forma procedimental. Aún más 
importante, debían tener presente el rendimiento 
durante el diseño de sus programas, lo que impli¬ 
caba un gran esfuerzo. En cambio, en una base de 
datos relacional, casi todas estas tareas de bajo 
nivel se realizan automáticamente por la base de 
datos, liberando al programador en el nivel lógi¬ 
co. Desde su escalada en el dominio en la década 
de 1980, el modelo relacional ha conseguido el rei¬ 
nado supremo entre todos los modelos de datos. 


La década de 1980 también fue testigo de una 
gran investigación en las bases de datos paralelas 
y distribuidas, así como del trabajo inicial en las 
bases de datos orientadas a objetos. 

• Principios de la década de 1990. El lenguaje SQL 
se diseñó fundamentalmente para las aplicaciones 
de ayuda a la toma de decisiones, que son intensi¬ 
vas en consultas, mientras que el objetivo princi¬ 
pal de las bases de datos en la década de 1980 fue 
las aplicaciones de procesamiento de transaccio¬ 
nes, que son intensivas en actualizaciones. La ayu¬ 
da a la toma de decisiones y las consultas reemer¬ 
gieron como una importante área de aplicación 
para las bases de datos. Las herramientas para ana¬ 
lizar grandes cantidades de datos experimentaron 
un gran crecimiento de uso. 

Muchos vendedores de bases de datos introdu¬ 
jeron productos de bases de datos paralelas en este 
periodo, así como también comenzaron ofrecer 
bases de datos relaciónales orientadas a objeto. 

• Finales de la década de 1990. El principal acon¬ 
tecimiento fue el crecimiento explosivo de World 
Wide Web. Las bases de datos se implantaron 
mucho más extensivamente que nunca antes. Los 
sistemas de bases de datos tienen ahora soporte 
para tasas de transacciones muy altas, así como 
muy alta fiabilidad y disponibilidad 24x7 (dispo¬ 
nibilidad 24 horas al día y 7 días a la semana, que 
significa que no hay tiempos de inactividad debi¬ 
dos a actividades de mantenimiento planificadas). 
Los sistemas de bases de datos también tuvieron 
interfaces Web a los datos. 


1.11. RESUMEN 


• Un sistema gestor de bases de datos (SGBD) con¬ 
siste en una colección de datos interrelacionados y 
una colección de programas para acceder a esos datos. 
Los datos describen una empresa particular. 

• El objetivo principal de un SGBD es proporcionar un 
entorno que sea tanto conveniente como eficiente para 
las personas que lo usan para la recuperación y alma¬ 
cenamiento de la información. 

• Los sistemas de bases de datos se diseñan para alma¬ 
cenar grandes cantidades de información. La gestión 
de los datos implica tanto la definición de estructuras 
para el almacenamiento de la información como la 
provisión de mecanismos para la manipulación de la 
información. Además, los sistemas de bases de datos 
deben proporcionar la seguridad de la información 
almacenada, en caso de caídas del sistema o intentos 
de accesos sin autorización. Si los datos están com¬ 
partidos por varios usuarios, el sistema debe evitar 
posibles resultados anómalos. 


• Un propósito principal de un sistema de bases de datos 
es proporcionar a los usuarios una visión abstracta de 
los datos. Es decir, el sistema esconde ciertos detalles 
de cómo los datos se almacenan y mantienen. 

• Por debajo de la estructura de la base de datos está el 
modelo de datos: una colección de herramientas con¬ 
ceptuales para describir los datos, las relaciones entre 
los datos, la semántica de los datos y las restricciones 
de los datos. El modelo de datos entidad-relación es un 
modelo de datos ampliamente usado, y proporciona una 
representación gráfica conveniente para ver los datos, 
las relaciones y las restricciones. El modelo de datos 
relacional se usa ampliamente para almacenar datos en 
las bases de datos. Otros modelos de datos son el mode¬ 
lo de datos orientado a objetos, el relacional orientado 
a objetos y modelos de datos semiestructurados. 

• El diseño general de la base de datos se denomina el 
esquema de la base de datos. Un esquema de base de 
datos se especifica con un conjunto de definiciones 
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que se expresan usando un lenguaje de definición de 
datos (LDD). 

• Un lenguaje de manipulación de datos (LMD) es 

un lenguaje que permite a los usuarios acceder o mani¬ 
pular los datos. Los LMD no procedimentales, que 
requieren que un usuario especifique sólo los datos 
que necesita, se usan ampliamente hoy día. 

• Los usuarios de bases de datos se pueden catalogar en 
varias clases, y cada clase de usuario usa habitual¬ 
mente diferentes tipos de interfaces de la base de datos. 

• Un sistema de bases de datos tiene varios subsistemas: 
— El subsistema gestor de transacciones es el res¬ 
ponsable de asegurar que la base de datos per¬ 
manezca en un estado consistente (correcto) a 
pesar de los fallos del sistema. El gestor de tran¬ 
sacciones también asegura que las ejecuciones 


de transacciones concurrentes ocurran sin con¬ 
flictos. 

— El subsistema procesador de consultas compila y 
ejecuta instrucciones LDD y LMD. 

— El subsistema gestor de almacenamiento es un 
módulo de programa que proporciona la interfaz 
entre los datos de bajo nivel almacenados en la 
base de datos y los programas de aplicación y las 
consultas enviadas al sistema. 

• Las aplicaciones de bases de datos se dividen nor¬ 
malmente en un parte frontal que se ejecuta en las 
máquinas cliente y una parte que se ejecuta en el dor¬ 
sal. En las arquitecturas de dos capas, el frontal se 
comunica directamente con una base de datos que se 
ejecuta en el dorsal. En las arquitecturas de tres capas, 
la parte dorsal se divide asimismo en un servidor de 
aplicaciones y en un servidor de bases de datos. 


TÉRMINOS DE REPASO 


Abstracción de datos. 

Administrador de la base de datos (ADB). 
Aplicaciones de sistemas de bases de datos. 
Concurrencia. 

Diccionario de datos. 

Ejemplar de la base de datos. 

Esquema. 

— Esquema de la base de datos. 

— Esquema físico. 

— Esquema lógico. 

Inconsistencia de datos. 

Independencia física de los datos. 
Lenguajes de bases de datos. 

— Lenguaje de consultas. 

— Lenguaje de definición de datos. 


Lenguaje de manipulación de datos. 

Máquinas cliente y servidor. 

Metadatos. 

Modelos de datos. 

— Modelo de datos orientado a objetos. 

— Modelo de datos relacional. 

— Modelo de datos relacional orientado a obje 
tos. 

— Modelo entidad-relación. 

Programa de aplicación. 

Restricciones de consistencia. 

Sistema de gestión de bases de datos (SGBD). 
Sistemas de archivos. 

Transacciones. 

Vistas de datos. 


EJERCICIOS 


1.1. ¿Cuáles son las cuatro diferencias principales entre 
un sistema de procesamiento de archivos y un SGBD? 

1.2. En este capítulo se han descrito las diferentes ventajas 
principales de un sistema gestor de bases de datos. ¿Cuá¬ 
les son los dos inconvenientes? 

1.3. Expliqúese la diferencia entre independencia de datos 
física y lógica. 

1.4. Lístense las cinco responsabilidades del sistema gestor de 
la base de datos. Para cada responsabilidad expliqúense 
los problemas que ocurrirían si no se realizara esa función. 

1.5. ¿Cuáles son las cinco funciones principales del admi¬ 
nistrador de la base de datos? 


1.6. Lístense siete lenguajes de programación que sean pro¬ 
cedimentales y dos que sean no procedimentales. ¿Qué 
grupo es más fácil de aprender a usar? Expliqúese la res¬ 
puesta. 

1.7. Lístense los seis pasos principales que se deberían dar 
en la realización de una base de datos para una empre¬ 
sa particular. 

1.8. Considérese un array de enteros bidimensional de tama¬ 
ño n x m que se va a usar en su lenguaje de programa¬ 
ción preferido. Usando el array como ejemplo, ilústre¬ 
se la diferencia (a) entre los tres niveles de abstracción 
y (b) entre esquema y ejemplares. 
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NOTAS BIBLIOGRÁFICAS 


A continuación se listan libros de propósito general, 
colecciones de artículos de investigación y sitios Web 
de bases de datos. 

Libros de texto que tratan los sistemas de bases de 
datos incluyen Abiteboul et al. [1995], Date [1995], 
Elmasri y Navathe [2000], O’Neil y O’Neil [2000], 
Ramakrishnan y Gehrke [2000] y Ullman [1988]. El tra¬ 
tamiento del procesamiento de transacciones en libros 
de texto se puede encontrar en Bernstein y Newcomer 
[1997] y Gray y Reuter [1993]. 

Varios libros incluyen colecciones de artículos de 
investigación sobre la gestión de bases de datos. Entre 
estos están Bancilhon y Buneman [1990], Date [1986], 
Date [1990], Kim [1995], Zaniolo et al. [1997], y Sto- 
nebraker y Hellerstein [1998]. 


Una revisión de los logros en la gestión de bases de 
datos y una valoración de los desafíos en la investiga¬ 
ción futura aparece en Silberschatz et al. [1990], Sil- 
berschatz et al. [1996] y Bernstein et al. [1998]. La pági¬ 
na inicial del grupo especial de interés de la ACM en 
gestión de datos (véase www.acm.org/sigmod) pro¬ 
porciona una gran cantidad de información sobre la 
investigación en bases de datos. Los sitios Web de los 
vendedores de bases de datos (véase el apartado Herra¬ 
mientas a continuación) proporciona detalles acerca de 
sus respectivos productos. 

Codd [1970] es el artículo histórico que introdujo el 
modelo relacional. En Fry y Sibley [1976] y Sibley [1976] 
se ofrecen discusiones referentes a la evolución de los 
SGBDs y al desarrollo de la tecnología de bases de datos. 


HERRAMIENTAS 


Hay un gran número de sistemas de bases de datos comer¬ 
ciales en uso actualmente. Los principales incluyen: 
DB2 de IBM (www.ibm.com/software/data), Oracle 
(www.oracle.com), Microsoft SQL Server (www.micro- 
soft.com/sql), Informix (www.informix.com) y Sybase 
(www.sybase.com). Algunos de estos sistemas están dis¬ 
ponibles gratuitamente para uso personal o no comer¬ 
cial, o para desarrollo, pero no para implantación real. 


Hay también una serie de sistemas de bases de datos 
gratuitos/públicos; algunos ampliamente usados in¬ 
cluyen MySQL (www.mysql.com) y PostgresSQL 
(www.postgresql.org). 

Una lista más completa de enlaces a vendedores y 
otra información se encuentra disponible en la página 
inicial de este libro en www.research.bell-labs.com/ 
topic/books/db-book. 
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MODELOS DE DATOS 


U n modelo de datos es una colección de herramientas conceptuales 
para la descripción de datos, relaciones entre datos, semántica de los 
datos y restricciones de consistencia. En esta parte se estudiarán dos 
modelos de datos —el modelo entidad-relación y el modelo relacional. 

El modelo entidad-relación (E-R) es un modelo de datos de alto nivel. Está 
basado en una percepción de un mundo real que consiste en una colección de 
objetos básicos, denominados entidades, y de relaciones entre estos objetos. 

El modelo relaciona es un modelo de menor nivel. Usa una colección de tablas 
para representar tanto los datos como las relaciones entre los datos. Su sim¬ 
plicidad conceptual ha conducido a su adopción general; actualmente, una vasta 
mayoría de productos de bases de datos se basan en el modelo relacional. Los 
diseñadores formulan generalmente el diseño del esquema de la base de datos 
modelando primero los datos en alto nivel, usando el modelo E-R, y después 
traduciéndolo al modelo relacional. 

Se estudiarán otros modelos de datos más tarde en este libro. El modelo de 
datos orientado a objetos, por ejemplo, extiende la representación de entida¬ 
des añadiendo nociones de encapsulación, métodos (funciones) e identidad de 
objeto. El modelo de datos relacional orientado a objetos combina caracterís¬ 
ticas del modelo de datos orientado a objetos y del modelo de datos relacional. 
Los Capítulos 8 y 9 tratan respectivamente estos dos modelos de datos. 


CAPÍTULO 



MODELO ENTIDAD-RELACIÓN 


E L modelo de datos entidad-relación (E-R) está basado en una percepción del mundo 
real consistente en objetos básicos llamados entidades y de relaciones entre estos obje¬ 
tos. Se desarrolló para facilitar el diseño de bases de datos permitiendo la especifica¬ 
ción de un esquema de la empresa que representa la estructura lógica completa de una base 
de datos. El modelo de datos E-R es uno de los diferentes modelos de datos semánticos; el 
aspecto semántico del modelo yace en la representación del significado de los datos. El mode¬ 
lo E-R es extremadamente útil para hacer corresponder los significados e interacciones de las 
empresas del mundo real con un esquema conceptual. Debido a esta utilidad, muchas herra¬ 
mientas de diseño de bases de datos se basan en los conceptos del modelo E-R. 


2.1. CONCEPTOS BÁSICOS 


Hay tres nociones básicas que emplea el modelo de datos 
E-R: conjuntos de entidades, conjuntos de relaciones y 
atributos. 

2.1.1. Conjuntos de entidades 

Una entidad es una «cosa» u «objeto» en el mundo real 
que es distinguible de todos los demás objetos. Por ejem¬ 
plo, cada persona en un desarrollo es una entidad. Una 
entidad tiene un conjunto de propiedades, y los valores 
para algún conjunto de propiedades pueden identificar 
una entidad de forma unívoca. Por ejemplo, el D.N.l. 
67.789.901 identifica unívocamente una persona par¬ 
ticular en la empresa. Análogamente, se puede pensar 
en los préstamos bancarios como entidades, y un núme¬ 
ro de préstamo P-15 en la sucursal de Castellana iden¬ 
tifica unívocamente una entidad de préstamo. Una enti¬ 
dad puede ser concreta, como una persona o un libro, o 
puede ser abstracta, como un préstamo, unas vacacio¬ 
nes o un concepto. 

Un conjunto de entidades es un conjunto de enti¬ 
dades del mismo tipo que comparten las mismas pro¬ 
piedades, o atributos. El conjunto de todas las personas 
que son clientes en un banco dado, por ejemplo, se pue¬ 
den definir como el conjunto de entidades cliente. Aná¬ 
logamente, el conjunto de entidades préstamo podría 
representar el conjunto de todos los préstamos concedi¬ 
dos por un banco particular. Las entidades individuales 
que constituyen un conjunto se llaman la extensión del 
conjunto de entidades. Así, todos los clientes de un ban¬ 
co son la extensión del conjunto de entidades cliente. 


Los conjuntos de entidades no son necesariamente dis¬ 
juntos. Por ejemplo, es posible definir el conjunto de enti¬ 
dades de todos los empleados de un banco ( empleado ) y 
el conjunto de entidades de todos los clientes del banco 
(cliente). Una entidad persona puede ser una entidad 
empleado , una entidad cliente, ambas cosas, o ninguna. 

Una entidad se representa mediante un conjunto de 
atributos. Los atributos describen propiedades que 
posee cada miembro de un conjunto de entidades. La 
designación de un atributo para un conjunto de entida¬ 
des expresa que la base de datos almacena información 
similar concerniente a cada entidad del conjunto de enti¬ 
dades; sin embargo, cada entidad puede tener su propio 
valor para cada atributo. Posibles atributos del conjun¬ 
to de entidades cliente son id-cliente, nombre-cliente, 
calle-cliente y ciudad-cliente. En la vida real, habría 
más atributos, tales como el número de la calle, el núme¬ 
ro del portal, la provincia, el código postal, y la comu¬ 
nidad autónoma, pero no se incluyen en el ejemplo sim¬ 
ple. Posibles atributos del conjunto de entidades 
préstamo son número-préstamo e importe. 

Cada entidad tiene un valor para cada uno de sus 
atributos. Por ejemplo, una entidad cliente en concreto 
puede tener el valor 32.112.312 para id-cliente, el valor 
Santos para nombre-cliente, el valor Mayor para calle- 
cliente y el valor Peguerinos para ciudad-cliente. 

El atributo id-cliente se usa para identificar unívo¬ 
camente a los clientes, dado que no hay más de un clien¬ 
te con el mismo nombre, calle y ciudad. En los Estados 
Unidos, muchas empresas encuentran conveniente usar 
el número seguridad-social de una persona 1 como un 


1 En España se asigna a cada persona del país un número único, deno¬ 
minado número del documento nacional de identidad (D.N.l.) para 
identificarla unívocamente. Se supone que cada persona tiene un 
único D.N.l., y no hay dos personas con el mismo D.N.l. 
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atributo cuyo valor identifica unívocamente a la perso¬ 
na. En general la empresa tendría que crear y asignar 
un identificador a cada cliente. 

Para cada atributo hay un conjunto de valores per¬ 
mitidos, llamados el dominio, o el conjunto de valo¬ 
res, de ese atributo. El dominio del atributo nombre- 
cliente podría ser el conjunto de todas las cadenas de 
texto de una cierta longitud. Análogamente, el dominio 
del atributo número-préstamo podría ser el conjunto de 
todas las cadenas de la forma «P-n», donde n es un ente¬ 
ro positivo. 

Una base de datos incluye así una colección de con¬ 
juntos de entidades, cada una de las cuales contiene un 
número de entidades del mismo tipo. En la Figura 2.1 se 
muestra parte de una base de datos de un banco que cons¬ 
ta de dos conjuntos de entidades, cliente y préstamo. 

Formalmente, un atributo de un conjunto de enti¬ 
dades es una función que asigna al conjunto de enti¬ 
dades un dominio. Como un conjunto de entidades pue¬ 
de tener diferentes atributos, cada entidad se puede 
describir como un conjunto de pares (atributo,valor), 
un par para cada atributo del conjunto de entidades. Por 
ejemplo, una entidad concreta cliente se puede descri¬ 
bir mediante el conjunto {( id-cliente , 67.789.901), 
(. nombre-cliente , López), ( calle-cliente , Mayor), ( ciu¬ 
dad-cliente ', Peguerinos)}, queriendo decir que la enti¬ 
dad describe una persona llamada López que tiene 
D.N.l. número 67.789.901, y reside en la calle Mayor 
en Peguerinos. Se puede ver, en este punto, que existe 
una integración del esquema abstracto con el desarro¬ 
llo real de la empresa que se está modelando. Los valo¬ 
res de los atributos que describen una entidad consti¬ 
tuirán una porción significante de los datos almacenados 
en la base de datos. 

Un atributo, como se usa en el modelo E-R, se pue¬ 
de caracterizar por los siguientes tipos de atributo. 

• Atributos simples y compuestos. En los ejemplos 
considerados hasta ahora, los atributos han sido sim¬ 
ples; es decir, no están divididos en subpartes. Los 


atributos compuestos, en cambio, se pueden divi¬ 
dir en subpartes (es decir, en otros atributos). Por 
ejemplo, nombre-cliente podría estar estructurado 
como un atributo compuesto consistente en nom¬ 
bre, primer-apellido y segundo-apellido. Usar atri¬ 
butos compuestos en un esquema de diseño es una 
buena elección si el usuario desea referirse a un atri¬ 
buto completo en algunas ocasiones y, en otras, a 
algún componente del atributo. Se podrían haber 
sustituido los atributos del conjunto de entidades 
cliente, calle-cliente y ciudad-cliente, por el atri¬ 
buto compuesto dirección-cliente, con los atribu¬ 
tos calle, ciudad, provincia, y código-postal 2 . Los 
atributos compuestos ayudan a agrupar los atribu¬ 
tos relacionados, haciendo los modelos más claros. 

Nótese también que un atributo compuesto pue¬ 
de aparecer como una jerarquía. Volviendo al ejem¬ 
plo del atributo compuesto dirección-cliente, su 
componente calle puede ser a su vez dividido en 
número-calle, nombre-calle y piso. Estos ejemplos 
de atributos compuestos para el conjunto de enti¬ 
dades cliente se representa en la Figura 2.2. 

• Atributos monovalorados y multivalorados. Los 

atributos que se han especificado en los ejemplos 
tienen todos un valor sólo para una entidad con¬ 
creta. Por ejemplo, el atributo número-préstamo 
para una entidad préstamo específico, referencia a 
un único número de préstamo. Tales atributos se 
llaman monovalorados. Puede haber ocasiones en 
las que un atributo tiene un conjunto de valores para 
una entidad específica. Considérese un conjunto de 
entidades empleado con el atributo número-teléfo¬ 
no. Cualquier empleado particular puede tener cero, 
uno o más números de teléfono. Este tipo de atri¬ 
buto se llama multivalorado. En ellos, se pueden 
colocar apropiadamente límites inferior y superior 
en el número de valores en el atributo multivalo¬ 
rado. Como otro ejemplo, un atributo nombre- 
subordinado del conjunto de entidades empleado 


2 Se asume el formato de calle-cliente y dirección usado en España, 
que incluye un código postal numérico llamado «código postal». 
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FIGURA 2.1. Conjunto de entidades cliente y préstamo. 
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Atributos 
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nombre-cliente 
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FIGURA 2.2. Atributos compuestos nombre-cliente y dirección-cliente. 


sería multivalorado, ya que un empleado en con¬ 
creto podría tener cero, uno o más subordinados. 

Cuando sea apropiado se pueden establecer 
límites superior e inferior en el número de valores 
de un atributo multivalorado. Por ejemplo, un ban¬ 
co puede limitar el número de números de teléfo¬ 
no almacenados para un único cliente a dos. Colo¬ 
cando límites en este caso, se expresa que el 
atributo número-teléfono del conjunto de entida¬ 
des cliente puede tener entre cero y dos valores. 

• Atributos derivados. El valor para este tipo de atri¬ 
buto se puede derivar de los valores de otros atri¬ 
butos o entidades relacionados. Por ejemplo, sea 
el conjunto de entidades cliente que tiene un atri¬ 
buto préstamos que representa cuántos préstamos 
tiene un cliente en el banco. Ese atributo se puede 
derivar contando el número de entidades présta¬ 
mo asociadas con ese cliente. 

Como otro ejemplo, considérese que el con¬ 
junto de entidades empleado tiene un atributo edad, 
que indica la edad del cliente. Si el conjunto de 
entidades cliente tiene también un atributo fecha- 
de-nacimiento, se puede calcular edad a partir de 
fecha-de-nacimiento y de la fecha actual. Así, edad 
es un atributo derivado. En este caso , fecha-de- 
nacimiento y antigüedad pueden serlo, ya que 
representan el primer día en que el empleado 
comenzó a trabajar para el banco y el tiempo total 
que el empleado lleva trabajando para el banco, 
respectivamente. El valor de antigüedad se puede 
derivar del valor de fecha-comienzo y de la fecha 
actual. En este caso, fecha-comienzo se puede 
conocer como atributo base o atributo almacena¬ 
do. El valor de un atributo derivado no se alma¬ 
cena, sino que se calcula cuando sea necesario. 

Un atributo toma un valor nulo cuando una entidad 
no tiene un valor para un atributo. El valor nulo tam¬ 
bién puede indicar «no aplicable», es decir, que el valor 
no existe para la entidad. Por ejemplo, una persona pue¬ 
de no tener segundo nombre de pila. Nulo puede tam¬ 
bién designar que el valor de un atributo es desconoci¬ 
do. Un valor desconocido puede ser, bien perdido (el 


valor existe pero no se tiene esa información) o desco¬ 
nocido (no se conoce si el valor existe realmente o no). 

Por ejemplo, si el valor nombre para un cliente par¬ 
ticular es nulo, se asume que el valor es perdido, ya que 
cada cliente debe tener un nombre. Un valor nulo para 
el atributo piso podría significar que la dirección no 
incluye un piso (no aplicable), que existe piso pero no 
se conoce cuál es (perdido), o que no se sabe si el piso 
forma parte o no de la dirección del cliente (descono¬ 
cido). 

Una base de datos para una empresa bancaria puede 
incluir diferentes conjuntos de entidades. Por ejemplo, 
además del mantenimiento de clientes y préstamos, el 
banco también proporciona cuentas, que se representan 
mediante el conjunto de entidades cuenta con atributos 
número-cuenta y saldo. También, si el banco tiene un 
número de sucursales diferentes, se puede mantener infor¬ 
mación acerca de todas las sucursales del banco. Cada 
conjunto de entidades sucursal se describe mediante los 
atributos nombre-sucursal, ciudad-sucursal y activo. 

2.1.2. Conjuntos de relaciones 

Una relación es una asociación entre diferentes enti¬ 
dades. Por ejemplo, se puede definir una relación que 
asocie al cliente López con el préstamo P-15. Esta rela¬ 
ción especifica que López es un cliente con el préstamo 
número P-15. 

Un conjunto de relaciones es un conjunto de rela¬ 
ciones del mismo tipo. Formalmente es una relación 
matemática con n > = 2 de conjuntos de entidades (posi¬ 
blemente no distintos). Si E l ,E 2 ,...,E n son conjuntos de 
entidades, entonces un conjunto de relaciones R es un 
subconjunto de: 

{(e 1 ,e 2 ,...,e n )\ e 1 EE l ,e 2 <EE 2 . e n B E„} 

donde (e { ,e 2 ,...e n ) es una relación. 

Considérense las dos entidades cliente y préstamo 
de la Figura 2.1. Se define el conjunto de relaciones 
prestatario para denotar la asociación entre clientes y 
préstamos bancarios que los clientes tengan. Esta aso¬ 
ciación se describe en la Figura 2.3. 
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FIGURA 2.3. Conjunto de relaciones prestatario. 


Como otro ejemplo, considérense los dos conjuntos 
de entidades préstamo y sucursal. Se puede definir el 
conjunto de relaciones sucursal-préstamo para denotar 
la asociación entre un préstamo y la sucursal en que se 
mantiene ese préstamo. 

La asociación entre conjuntos de entidades se cono¬ 
ce como participación ; es decir, los conjuntos de enti¬ 
dades £j, E 2 ,..., E n participan en el conjunto de rela¬ 
ciones R. Un ejemplar de relación en un esquema E-R 
representa que existe una asociación entre las entidades 
denominadas en la empresa del mundo real que se mode¬ 
la. Como ilustración, el cliente individual López, que 
tiene D.N.I. 67.789.901, y la entidad préstamo P-15 par¬ 
ticipan en un ejemplar de relación de prestatario. Este 
ejemplar de relación representa que, en la empresa del 
mundo real, la persona llamada López cuyo número de 
D.N.I. es 67.789.901 ha tomado un préstamo que está 
numerado como P-15. 

La función que desempeña una entidad en una rela¬ 
ción se llama papel de la entidad. 

Debido a que los conjuntos de entidades que partici¬ 
pan en un conjunto de relaciones son generalmente dis¬ 
tintos, los papeles están implícitos y no se especifican 
normalmente. Sin embargo, son útiles cuando el signi¬ 
ficado de una relación necesita aclaración. Tal es el caso 
cuando los conjuntos de entidades de una relación no 
son distintos; es decir, el mismo conjunto de entidades 
participa en una relación más de una vez con diferentes 
papeles. En este tipo de conjunto de relaciones, que se 
llama algunas veces conjunto de relaciones recursivo, 
es necesario hacer explícitos los papeles para especifi¬ 
car cómo participa una entidad en un ejemplar de rela¬ 
ción. Por ejemplo, considérese una conjunto de entida¬ 
des empleado que almacena información acerca de todos 
los empleados del banco. Se puede tener un conjunto de 
relaciones trabaja-para que se modela mediante pares 
ordenados de entidades empleado. El primer empleado 
de un par toma el papel de trabajador , mientras el segun¬ 
do toma el papel de jefe. De esta manera, todas las rela¬ 
ciones trabaja-para son pares (trabajador, jefe); los pares 
(jefe, trabajador) están excluidos. 

Una relación puede también tener atributos des¬ 
criptivos. Considérese un conjunto de relaciones impo- 


sitor con conjuntos de entidades cliente y cuenta. Se 
podría asociar el atributo fecha-acceso a esta relación 
para especificar la fecha más reciente en que un clien¬ 
te accedió a una cuenta. La relación impositor entre las 
entidades correspondientes al cliente García y la cuen¬ 
ta C-217 se describen mediante {( fecha-acceso , 23 mayo 
2002)}, lo que significa que la última vez que García 
accedió a la cuenta C-217 fue el 23 de mayo de 2002. 

Como otro ejemplo de atributos descriptivos para 
relaciones, supóngase que se tienen los conjuntos de 
entidades estudiante y asignatura que participan en una 
relación matriculado. Se podría desear almacenar un 
atributo descriptivo para créditos con la relación, para 
registrar si el estudiante se ha matriculado de la asig¬ 
natura para obtener créditos o sólo como oyente. 

Un ejemplar de relación en un conjunto de relacio¬ 
nes determinado debe ser identificado unívocamente a 
partir de sus entidades participantes, sin usar los atri¬ 
butos descriptivos. Para comprender este punto supón¬ 
gase que deseemos modelar todas las fechas en las que 
un cliente ha accedido a una cuenta. El atributo mono- 
valorado fecha-acceso puede almacenar sólo una única 
fecha de acceso. No se pueden representar varias fechas 
de acceso por varios ejemplares de relación entre el mis¬ 
mo cliente y cuenta, ya que los ejemplares de relación 
no estarían identificados unívocamente por las entida¬ 
des participantes. La forma correcta de manejar este 
caso es crear un atributo multivalorado fechas-acceso 
que pueda almacenar todas las fechas de acceso. 

Sin embargo, puede haber más de un conjunto de 
relaciones que involucren los mismos conjuntos de enti¬ 
dades. En nuestro ejemplo los conjuntos de entidades 
cliente y préstamo participan en el conjunto de relacio¬ 
nes prestatario. Además, supóngase que cada préstamo 
deba tener otro cliente que sirva como avalista para el 
préstamo. Entonces los conjuntos de entidades cliente 
y préstamo pueden participar en otro conjunto de rela¬ 
ciones: avalista. 

Los conjuntos de relaciones prestatario y sucursal- 
préstamo proporcionan un ejemplo de un conjunto de 
relaciones binario, es decir, uno que implica dos con¬ 
juntos de entidades. La mayoría de los conjuntos de rela¬ 
ciones en un sistema de bases de datos son binarios. 
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Ocasionalmente, sin embargo, los conjuntos de rela¬ 
ciones implican más de dos conjuntos de entidades. 

Por ejemplo, considérense los conjuntos de entida¬ 
des empleado , sucursal y trabajo. Ejemplos de las enti¬ 
dades trabajo podrían ser director, cajero, auditor y 
otros. Las entidades trabajo pueden tener los atributos 
puesto y nivel. El conjunto de relaciones trabaja-en 
entre empleado, sucursal y trabajo es un ejemplo de 
una relación ternaria. Una relación ternaria entre San¬ 
tos, Navacerrada y director indica que Santos actúa de 


director de la sucursal Navacerrada. Santos también 
podría actuar como auditor de la sucursal Centro, que 
estaría representado por otra relación. Podría haber otra 
relación entre Gómez, Centro y cajero, indicando que 
Gómez actúa como cajero en la sucursal Centro. 

El número de conjuntos de entidades que participan 
en un conjunto de relaciones es también el grado del 
conjunto de relaciones. Un conjunto de relaciones bina¬ 
rio tiene grado 2; un conjunto de relaciones ternario tie¬ 
ne grado 3. 


2.2. RESTRICCIONES 


Un esquema de desarrollo E-R puede definir ciertas res¬ 
tricciones a las que los contenidos de la base de datos 
se deben adaptar. En este apartado se examina la corres¬ 
pondencia de cardinalidades y las restricciones de par¬ 
ticipación, que son dos de los tipos más importantes de 
restricciones. 

2.2.1. Correspondencia de cardinalidades 

La correspondencia de cardinalidades, o razón de car- 
dinalidad, expresa el número de entidades a las que otra 
entidad puede estar asociada vía un conjunto de rela¬ 
ciones. 

La correspondencia de cardinalidades es la más útil 
describiendo conjuntos de relaciones binarias, aunque 
ocasionalmente contribuye a la descripción de conjun¬ 
tos de relaciones que implican más de dos conjuntos de 
entidades. Este apartado se centrará en conjuntos de 
relaciones binarias únicamente. 

Para un conjunto de relaciones binarias R entre los 
conjuntos de entidades A y B, la correspondencia de car¬ 
dinalidades debe ser una de las siguientes: 

• Uno a uno. Una entidad en A se asocia con a lo 
sumo una entidad en B, y una entidad en B se aso¬ 
cia con a lo sumo una entidad en A (véase la Figu¬ 
ra 2.4a). 



A B A B 



(a) (b) 


FIGURA 2.5. Correspondencia de cardinalidades. (a) Varios 
a uno. (b) Varios a varios. 


• Uno a varios. Una entidad en A se asocia con cual¬ 
quier número de entidades en B (ninguna o varias). 
Una entidad en B, sin embargo, se puede asociar con 
a lo sumo una entidad en A (véase la Figura 2.4b). 

• Varios a uno. Una entidad en A se asocia con a lo 
sumo una entidad en B. Una entidad en B, sin embar¬ 
go, se puede asociar con cualquier número de enti¬ 
dades (ninguna o varias) en A (véase la Figura 2.5 a). 

• Varios a varios. Una entidad en A se asocia con 
cualquier número de entidades (ninguna o varias) 
en B, y una entidad en B se asocia con cualquier 
número de entidades (ninguna o varias) en A (véa¬ 
se la Figura 2.5b). 

La correspondencia de cardinalidades apropiada para 
un conjunto de relaciones particular depende obvia¬ 
mente de la situación del mundo real que el conjunto de 
relaciones modela. 

Como ilustración considérese el conjunto de rela¬ 
ciones prestatario. Si en un banco particular un présta¬ 
mo puede pertenecer únicamente a un cliente y un clien¬ 
te puede tener varios préstamos, entonces el conjunto 
de relaciones de cliente a préstamo es uno a varios. Si 
un préstamo puede pertenecer a varios clientes (como 
préstamos que se toman en conjunto por varios socios 
de un negocio) el conjunto de relaciones es varios a 
varios. Este tipo de relación se describe en la Figura 2.3. 
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2.2.2. Restricciones de participación 

La participación de un conjunto de entidades E en un 
conjunto de relaciones R se dice que es total si cada 
entidad en E participa al menos en una relación en R. 
Si sólo algunas entidades en E participan en relaciones 
en R, la participación del conjunto de entidades E en la 
relación R se llama parcial. Por ejemplo, se puede espe¬ 
rar que cada entidad préstamo esté relacionada con al 


menos un cliente mediante la relación prestatario. Por 
lo tanto, la participación de préstamo en el conjunto de 
relaciones prestatario es total. En cambio, un individuo 
puede ser cliente de un banco tenga o no tenga un prés¬ 
tamo en el banco. Así, es posible que sólo algunas de 
las entidades cliente estén relacionadas con el conjun¬ 
to de entidades préstamo mediante la relación presta¬ 
tario, y la participación de cliente en el conjunto de rela¬ 
ciones prestatario es por lo tanto parcial. 


2.3. CLAVES 


Es necesario tener una forma de especificar cómo las 
entidades dentro de un conjunto de entidades dado y las 
relaciones dentro de un conjunto de relaciones dado son 
distinguibles. Conceptualmente las entidades y rela¬ 
ciones individuales son distintas; desde una perspecti¬ 
va de bases de datos, sin embargo, la diferencia entre 
ellas se debe expresar en término de sus atributos. 

Por lo tanto, los valores de los atributos de una enti¬ 
dad deben ser tales que permitan identificar unívoca¬ 
mente a la entidad. En otras palabras, no se permite que 
ningún par de entidades tengan exactamente los mis¬ 
mos valores de sus atributos. 

Una clave permite identificar un conjunto de atribu¬ 
tos suficiente para distinguir las entidades entre sí. Las 
claves también ayudan a identificar unívocamente a las 
relaciones y así a distinguir las relaciones entre sí. 

2.3.1. Conjuntos de entidades 

Una superclave es un conjunto de uno o más atributos 
que, tomados colectivamente, permiten identificar de 
forma única una entidad en el conjunto de entidades. 
Por ejemplo, el atributo id-cliente del conjunto de enti¬ 
dades cliente es suficiente para distinguir una entidad 
cliente de las otras. Así, id-cliente es una superclave. 
Análogamente, la combinación de nombre-cliente e id- 
cliente es una superclave del conjunto de entidades clien¬ 
te. El atributo nombre-cliente de cliente no es una super¬ 
clave, porque varias personas podrían tener el mismo 
nombre. 

El concepto de una superclave no es suficiente para 
lo que aquí se propone, ya que, como se ha visto, una 
superclave puede contener atributos innecesarios. Si K 
es una superclave, entonces también lo es cualquier 
superconjunto de K. A menudo interesan las supercla- 
ves tales que los subconjuntos propios de ellas no son 
superclave. Tales superclaves mínimas se llaman cla¬ 
ves candidatas. 

Es posible que conjuntos distintos de atributos pudie¬ 
ran servir como clave candidata. Supóngase que una 
combinación de nombre-cliente y calle-cliente es sufi¬ 
ciente para distinguir entre los miembros del conjunto 
de entidades cliente. Entonces, los conjuntos {id-clien¬ 
te} y {nombre-cliente, calle-cliente} son claves candi¬ 


datas. Aunque los atributos id-cliente y nombre-cliente 
juntos puedan distinguir entidades cliente, su combina¬ 
ción no forma una clave candidata, ya que el atributo 
id-cliente por sí solo es una clave candidata. 

Se usará el término clave primaria para denotar una 
clave candidata que es elegida por el diseñador de la 
base de datos como elemento principal para identificar 
las entidades dentro de un conjunto de entidades. Una 
clave (primaria, candidata y superclave) es una propie¬ 
dad del conjunto de entidades, más que de las entida¬ 
des individuales. Cualesquiera dos entidades indivi¬ 
duales en el conjunto no pueden tener el mismo valor 
en sus atributos clave al mismo tiempo. La designación 
de una clave representa una restricción en el desarrollo 
del mundo real que se modela. 

Las claves candidatas se deben designar con cuida¬ 
do. Como se puede comprender, el nombre de una per¬ 
sona es obviamente insuficiente, ya que hay mucha gen¬ 
te con el mismo nombre. En España, el D.N.l. puede 
ser una clave candidata. Como los no residentes en Espa¬ 
ña normalmente no tienen D.N.L, las empresas inter¬ 
nacionales pueden generar sus propios identificadores 
únicos. Una alternativa es usar alguna combinación úni¬ 
ca de otros atributos como clave. 

La clave primaria se debería elegir de manera que 
sus atributos nunca, o muy raramente, cambien. Por 
ejemplo, el campo dirección de una persona no debería 
formar parte de una clave primaria, porque probable¬ 
mente cambiará. Los números de D.N.L, por otra par¬ 
te, es seguro que no cambiarán. Los identificadores úni¬ 
cos generados por empresas generalmente no cambian, 
excepto si se fusionan dos empresas; en tal caso el mis¬ 
mo identificador puede haber sido emitido por ambas 
empresas y es necesario la reasignación de identifica¬ 
dores para asegurarse de que sean únicos. 

2.3.2. Conjuntos de relaciones 

La clave primaria de un conjunto de entidades permite 
distinguir entre las diferentes entidades del conjunto. 
Se necesita un mecanismo similar para distinguir entre 
las diferentes relaciones de un conjunto de relaciones. 

Sea R un conjunto de relaciones que involucra los 
conjuntos de entidades £j, E 2 ,..., E n . Sea clave-prima- 


24 



CAPÍTULO 2 MODELO ENTIDAD-RELACIÓN 


ria(Ej) el conjunto de atributos que forma la clave pri¬ 
maria para el conjunto de entidades E¡. 

Asúmase por el momento que los nombres de los 
atributos de todas las claves primarias son únicos y que 
cada conjunto de entidades participa sólo una vez en la 
relación. La composición de la clave primaria para un 
conjunto de relaciones depende de la estructura de los 
atributos asociados al conjunto de relaciones R. 

Si el conjunto de relaciones R no tiene atributos aso¬ 
ciados, entonces el conjunto de atributos: 

clave-primaria(E { ) U clave-primaria(E 2 ) U ... 

U clave-primaria(E n ) 

describe una relación individual en el conjunto R. 

Si el conjunto de relaciones R tiene atributos a u 
a 2 ,...,a m asociados a él, entonces el conjunto de atri¬ 
butos 

clave-primaria( £j) U clave-primaria(E 2 ) U... 

U clave-primaria(E n ) U {a { , a 2 , 

describe una relación individual en el conjunto R. 

En ambos casos, el conjunto de atributos 

clave-primaria(E { ) U clave-primaria(E 2 ) U ... 

U clave-primaria(E n ) 

forma una superclave para el conjunto de relaciones. 

En el caso de que los nombres de atributos de las cla¬ 
ves primarias no sean únicos en todos los conjuntos de 
entidades, los atributos se renombran para distinguir¬ 
los; el nombre del conjunto de entidades combinado con 
el atributo formaría un nombre único. En el caso de que 


un conjunto de entidades participe más de una vez en 
un conjunto de relaciones (como en la relación traba- 
ja-para del Apartado 2.1.2) el nombre del papel se usa 
en lugar del nombre del conjunto de entidades para for¬ 
mar un nombre único de atributo. 

La estructura de la clave primaria para el conjunto 
de relaciones depende de la correspondencia de cardi- 
nalidades asociada al conjunto de relaciones. Como 
ilustración, considérese el conjunto de entidades clien¬ 
te y cuenta, y un conjunto de relaciones impositor, con 
el atributo fecha-acceso del Apartado 2.1.2. Supónga¬ 
se que el conjunto de relaciones es varios a varios. 
Entonces la clave primaria de impositor consiste en la 
unión de las claves primarias de cliente y cuenta. Sin 
embargo, si un cliente puede tener sólo una cuenta 
— es decir, si la relación impositor es varios a uno de 
cliente a cuenta— entonces la clave primaria de impo¬ 
sitor es simplemente la clave primaria de cliente. Aná¬ 
logamente, si la relación es varios a uno de cuenta a 
cliente —es decir, cada cuenta pertenece a lo sumo a 
un cliente — entonces la clave primaria de impositor 
es simplemente la clave primaria de cuenta. Para re¬ 
laciones uno a uno se puede usar cualquier clave pri¬ 
maria. 

Para las relaciones no binarias, si no hay restriccio¬ 
nes de cardinalidad, entonces la superclave formada 
como se describió anteriormente en este apartado es la 
única clave candidata, y se elige como clave primaria. 
La elección de la clave primaria es más complicada si 
aparecen restricciones de cardinalidad. Ya que no se ha 
discutido cómo especificar restricciones de cardinali¬ 
dad en relaciones no binarias, no se discutirá este aspec¬ 
to en este capítulo. Se considerará este aspecto con más 
detalle en el apartado 7.3. 


2.4. CUESTIONES DE DISEÑO 


Las nociones de conjunto de entidades y conjunto de 
relaciones no son precisas, y es posible definir un con¬ 
junto de entidades y las relaciones entre ellas de di¬ 
ferentes formas. En este apartado se examinan cuestio¬ 
nes básicas de diseño de un esquema de bases de datos 
E-R. El proceso de diseño se trata con más detalle en el 
Apartado 2.7.4. 

2.4.1. Uso de conjuntos de entidades 
o atributos 

Considérese el conjunto de entidades empleado con los 
atributos nombre-empleado y número-teléfono. Se pue¬ 
de argumentar fácilmente que un teléfono es una enti¬ 
dad por sí misma con atributos número-teléfono y ubi¬ 
cación (la oficina donde está ubicado el teléfono). Si se 
toma este punto de vista, el conjunto de entidades em¬ 
pleado debe ser redefinido como sigue: 


• El conjunto de entidades empleado con el atribu¬ 
to nombre-empleado 

• El conjunto de entidades teléfono con atributos 
número-teléfono y ubicación 

• La relación empleado-teléfono, que denota la aso¬ 
ciación entre empleados y los teléfonos que tienen. 

¿Cuál es, entonces, la diferencia principal entre esas 
dos definiciones de un empleado? Al tratar un teléfono 
como un atributo número-teléfono implica que cada 
empleado tiene precisamente un número de teléfono. Al 
tratar un teléfono como una entidad teléfono permite 
que los empleados puedan tener varios números de telé¬ 
fono (incluido ninguno) asociados a ellos. Sin embar¬ 
go, se podría definir fácilmente número-teléfono como 
un atributo multivalorado para permitir varios teléfo¬ 
nos por empleado. 
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La diferencia principal es que al tratar un teléfono 
como una entidad se modela mejor una situación en la 
que se puede querer almacenar información extra sobre 
un teléfono, como su ubicación, su tipo (móvil, video¬ 
teléfono o fijo) o quiénes comparten un teléfono. Así, 
al tratar un teléfono como una entidad es más general 
que tratarlo como un atributo y es apropiado cuando la 
generalidad pueda ser de utilidad. 

En cambio, no sería adecuado tratar el atributo nom¬ 
bre-empleado como una entidad; es difícil argumentar 
que nombre-empleado sea una entidad por sí mismo (a 
diferencia del teléfono). Así, es apropiado tener nom¬ 
bre-empleado como un atributo del conjunto de entida¬ 
des empleado. 

Por tanto, aparecen dos cuestiones naturales: ¿qué 
constituye un atributo? y ¿qué constituye un conjunto 
de entidades? Por desgracia no hay respuestas simples. 
Las distinciones dependen principalmente de la estruc¬ 
tura de la empresa del mundo real que se esté mode¬ 
lando y de la semántica asociada con el atributo en cues¬ 
tión. 

Un error común es usar la clave primaria de un con¬ 
junto de entidades como un atributo de otro conjunto 
de entidades, en lugar de usar una relación. Por ejem¬ 
plo, es incorrecto modelar id-cliente como un atributo 
de préstamo incluso si cada préstamo tiene sólo un clien¬ 
te. La relación prestatario es la forma correcta de repre¬ 
sentar la conexión entre préstamos y clientes, ya que 
hace su conexión explícita en lugar de implícita median¬ 
te un atributo. 

Otro error relacionado que se comete es designar a 
los atributos de la clave primaria de los conjuntos de 
entidades relacionados como atributos del conjunto de 
relaciones. Esto no se debería hacer, ya que los atribu¬ 
tos de la clave primaria son ya implícitos en la relación. 

2.4.2. Uso de conjuntos de entidades 
o conjuntos de relaciones 

No siempre está claro si es mejor expresar un objeto 
mediante un conjunto de entidades o mediante un con¬ 
junto de relaciones. En el Apartado 2.1.1 se asumió que 
un préstamo se modelaba como una entidad. Una alter¬ 
nativa es modelar un préstamo no como una entidad, 
sino como una relación entre clientes y sucursales, con 
número-préstamo e importe como atributos descripti¬ 
vos. Cada préstamo se representa mediante una relación 
entre un cliente y una sucursal. 

Si cada préstamo está asociado exactamente con un 
cliente y con una sucursal, se puede encontrar satisfac¬ 
torio el diseño en el que un préstamo se representa como 
una relación. Sin embargo, con este diseño no se pue¬ 
de representar convenientemente una situación en que 
varios clientes comparten un préstamo. Habría que defi¬ 
nir una relación separada para cada prestatario de ese 
préstamo común. Entonces habría que replicar los valo¬ 
res para los atributos descriptivos número-préstamo e 
importe en cada una de estas relaciones. Cada una de 


estas relaciones debe, por supuesto, tener el mismo valor 
para los atributos descriptivos número-préstamo e 
importe. 

Surgen dos problemas como resultado de esta répli¬ 
ca: 1) los datos se almacenan varias veces, desperdi¬ 
ciando espacio de almacenamiento; y 2) las actualiza¬ 
ciones dejan potencialmente los datos en un estado 
inconsistente, en el que los valores difieren en dos rela¬ 
ciones para atributos que se supone tienen el mismo 
valor. El asunto de cómo evitar esta réplica se trata for¬ 
malmente mediante la teoría de la normalización , dis¬ 
cutida en el Capítulo 7. 

El problema de la réplica de los atributos número- 
préstamo e importe no aparece en el diseño original del 
Apartado 2.1.1. porque préstamo es un conjunto de enti¬ 
dades. 

Una posible guía para determinar si usar un conjun¬ 
to de entidades o un conjunto de relaciones es designar 
un conjunto de relaciones para describir una acción que 
ocurre entre entidades. Este enfoque puede también ser 
útil para decidir si ciertos atributos se pueden expresar 
más apropiadamente como relaciones. 

2.4.3. Conjuntos de relaciones binarias 
o n-arias 

Las relaciones en las bases de datos son generalmente 
binarias. Algunas relaciones que parecen no ser bina¬ 
rias podrían ser representadas mejor con varias rela¬ 
ciones binarias. Por ejemplo, uno podría crear una rela¬ 
ción ternaria padres, que relaciona un hijo con su padre 
y su madre. Sin embargo, tal relación se podría repre¬ 
sentar por dos relaciones binarias padre y madre , rela¬ 
cionando un hijo con su padre y su madre por separa¬ 
do. Al usar las dos relaciones padre y madre se permite 
registrar la madre de un niño incluso si no se conoce la 
identidad del padre; en la relación ternaria padres se 
necesitaría usar un valor nulo. En este caso es preferi¬ 
ble usar conjuntos de relaciones binarias. 

De hecho, siempre es posible reemplazar un conjunto 
de relaciones no binarias (n-aria, para n > 2) por un 
número de diferentes conjuntos de relaciones binarias. 
Por simplicidad, considérese el conjunto de relaciones 
abstracto R, ternario (n = 3), y los conjuntos de entida¬ 
des A, B, y C. Se sustituye el conjunto de relaciones R 
por un conjunto de entidades E y se crean tres conjun¬ 
tos de relaciones: 

• R a , relacionando Ey A 

• R b , relacionando Ey B 

• R c , relacionando Ey C 

Si el conjunto de relaciones R tiene atributos, éstos 
se asignan al conjunto de entidades E: por otra parte se 
crea un atributo de identificación especial para E (debi¬ 
do a que cada conjunto de entidades debe tener al menos 
un atributo para distinguir los miembros del conjunto). 
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Para cada relación ( a¡,b¡,c¡ ) del conjunto de relaciones 
R, se crea una nueva entidad e¡ en el conjunto de enti¬ 
dades E. Entonces, en cada uno de los tres nuevos con¬ 
juntos de relaciones, se inserta un nuevo miembro como 
sigue: 

• (e„a¡) en R A 

• (e p b¡) en R n 

• (e¡,c¡) en R c 

Se puede generalizar este proceso de una forma seme¬ 
jante a conjuntos de relaciones n-arias. Así, concep¬ 
tualmente, se puede restringir el modelo E-R para incluir 
sólo conjuntos de relaciones binarias. Sin embargo, esta 
restricción no siempre es deseable. 

• Un atributo de identificación puede haber sido cre¬ 
ado para el conjunto de entidades para representar 
el conjunto de relaciones. Este atributo, con los con¬ 
juntos de relaciones extra necesarios, incrementa 
la complejidad del diseño y (como se verá en el 
Apartado 2.9) los requisitos de almacenamiento. 

• Un conjunto de relaciones //-arias muestra más cla¬ 
ramente que varias entidades participan en una 
relación simple. 

• Podría no haber una forma de traducir restricciones 
en la relación ternaria en restricciones sobre rela¬ 
ciones binarias. Por ejemplo, considérese una res¬ 
tricción que dice que R es varios a uno de A, B a C; 
es decir, cada par de entidades de A y B se asocia 
con a lo sumo una entidad C. Esta restricción no se 
puede expresar usando restricciones de cardinali- 
dad sobre los conjuntos de relaciones R A , R B y R c . 

Considérese el conjunto de relaciones trabaja-en del 
Apartado 2.1.2 que relaciona empleado, sucursal y tra¬ 
bajo. No se puede dividir directamente trabaja-en en 
relaciones binarias entre empleado y sucursal y entre 
empleado y trabajo. Si se hiciese habría que registrar 
que Santos es director y auditor y que Santos trabaja en 
Navacerrada y Centro; sin embargo, no se podría regis¬ 
trar que Santos es director de Navacerrada y auditor de 
Centro, pero que no es auditor de Navacerrada y direc¬ 
tor de Centro. 

El conjunto de relaciones trabaja-en se puede divi¬ 
dir en relaciones binarias creando nuevos conjuntos de 
entidades como se describió anteriormente. Sin embar¬ 
go, no sería muy natural. 

2.4.4. Ubicación de los atributos 
de las relaciones 

La razón de cardinalidad de una relación puede afectar 
a la situación de los atributos de la relación. Los atri¬ 
butos de los conjuntos de relaciones uno a uno o uno a 
varios pueden estar asociados con uno de los conjuntos 
de entidades participantes, en lugar de con el conjunto 


de relaciones. Por ejemplo, especificamos que imposi- 
tor es un conjunto de relaciones uno a varios tal que un 
cliente puede tener varias cuentas, pero cada cuenta está 
asociada únicamente con un cliente. En este caso, el 
atributo fecha-acceso, que especifica cuándo accedió 
por última vez el cliente a la cuenta, podría estar aso¬ 
ciado con el conjunto de entidades cuenta, como se des¬ 
cribe en la Figura 2.6; para mantener la simplicidad de 
la figura sólo se muestran algunos de los atributos de 
los dos conjuntos de entidades. Como cada entidad cuen¬ 
ta participa en una relación con a lo sumo un ejemplar 
de cliente, hacer esta designación de atributos tendría 
el mismo significado que si se colocase fecha-acceso 
en el conjunto de relaciones impositor. Los atributos de 
un conjunto de relaciones uno a varios se pueden colo¬ 
car sólo en el conjunto de entidades de la parte «varios» 
de la relación. Por otra parte, para los conjuntos de enti¬ 
dades uno a uno, los atributos de la relación se pueden 
asociar con cualquiera de las entidades participantes. 

La decisión de diseño de dónde colocar los atribu¬ 
tos descriptivos en tales casos —como un atributo de la 
relación o de la entidad— podría reflejar las caracterís¬ 
ticas de la empresa que se modela. El diseñador puede 
elegir mantener fecha-acceso como un atributo de impo¬ 
sitor para expresar explícitamente que ocurre un acce¬ 
so en el punto de interacción entre los conjuntos de enti¬ 
dades cliente y cuenta. 

La elección de la colocación del atributo es más cla¬ 
ra para los conjuntos de relaciones varios a varios. Vol¬ 
viendo al ejemplo, especificamos el caso quizá más rea¬ 
lista de impositor que es un conjunto de relaciones varios 
a varios, expresando que un cliente puede tener una o 
más cuentas, y que una cuenta puede ser mantenida por 
uno o más clientes. Si se expresa la fecha en que un 
cliente específico accedió por última vez a una cuenta 
específica, fecha-acceso debe ser un atributo del con¬ 
junto de relaciones impositor, en lugar de una de las 
entidades participantes. Si fecha-acceso fuese un atri¬ 
buto de cuenta, por ejemplo, no se podría determinar 


cuenta (número-cuenta, 
cliente fecha-acceso) 
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FIGURA 2.6. Fecha-acceso como atributo del conjunto de 
entidades cuenta. 
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qué cliente hizo el acceso más reciente a una cuenta con¬ 
junta. Cuando un atributo se determina mediante la com¬ 
binación de los conjuntos de entidades participantes, en 
lugar de por cada entidad por separado, ese atributo debe 
estar asociado con el conjunto de relaciones varios a 


varios. La colocación de fecha-acceso como un atribu¬ 
to de la relación se describe en la Figura 2.7; de nuevo, 
para mantener la simplicidad de la figura, sólo se mues¬ 
tran algunos de los atributos de los dos conjuntos de 
entidades. 


2.5. DIAGRAMA ENTIDAD-RELACIÓN 


Como se vio brevemente en el Apartado 1.4, la estruc¬ 
tura lógica general de una base de datos se puede expre¬ 
sar gráficamente mediante un diagrama E-R. Los dia¬ 
gramas son simples y claros, cualidades que pueden ser 
responsables del amplio uso del modelo E-R. Tal dia¬ 
grama consta de los siguientes componentes principales: 

• Rectángulos, que representan conjuntos de enti¬ 
dades. 

• Elipses, que representan atributos. 

• Rombos, que representan relaciones. 

• Líneas, que unen atributos a conjuntos de entida¬ 
des y conjuntos de entidades a conjuntos de rela¬ 
ciones. 

• Elipses dobles, que representan atributos multi- 
valorados. 

• Elipses discontinuas, que denotan atributos deri¬ 
vados. 

• Líneas dobles, que indican participación total de 
una entidad en un conjunto de relaciones. 


• Rectángulos dobles, que representan conjuntos 
de entidades débiles (se describirán posteriormente 
en el Apartado 2.6). 

Considérese el diagrama entidad-relación de la Figu¬ 
ra 2.8, que consta de dos conjuntos de entidades, clien¬ 
te y préstamo, relacionadas a través de un conjunto de 
relaciones binarias prestatario. Los atributos asociados 
con cliente son id-cliente, nombre-cliente, calle-clien¬ 
te, y ciudad-cliente. Los atributos asociados con prés¬ 
tamo son número-préstamo e importe. Como se mues¬ 
tra en la Figura 2.8, los atributos de un conjunto de 
entidades que son miembros de la clave primaria están 
subrayados. 

El conjunto de relaciones prestatario puede ser varios 
a varios, uno a varios, varios a uno o uno a uno. Para 
distinguir entre estos tipos, se dibuja o una línea dirigi¬ 
da (—») o una línea no dirigida (—) entre el conjunto de 
relaciones y el conjunto de entidades en cuestión. 

• Una línea dirigida desde el conjunto de relaciones 
prestatario al conjunto de entidades préstamo espe- 


impositor (fecha-accceso) 



FIGURA 2.7. Fecha-acceso como atributo del conjunto de relaciones impositor. 
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FIGURA 2.8. Diagrama E-R correspondiente a clientes y préstamos. 


ciñca que prestatario es un conjunto de relaciones 
uno a uno, o bien varios a uno, desde cliente a prés¬ 
tamo: prestatario no puede ser un conjunto de rela¬ 
ciones varios a varios ni uno a varios, desde clien¬ 
te a préstamo. 

• Una línea no dirigida desde el conjunto de rela¬ 
ciones prestatario al conjunto de relaciones prés¬ 
tamo especifica que prestatario es o bien un con¬ 


junto de relaciones varios a varios, o bien uno a 
varios, desde cliente a préstamo. 

Volviendo al diagrama E-R de la Figura 2.8, se ve 
que el conjunto de relaciones prestatario es varios a 
varios. Si el conjunto de relaciones prestatario fuera 
uno a varios, desde cliente a préstamo, entonces la línea 
desde prestatario a cliente sería dirigida, con una fle¬ 
cha apuntando al conjunto de entidades cliente (Figura 
2.9a). Análogamente, si el conjunto de relaciones pres¬ 



te) 



(b) 



te) 


FIGURA 2.9. Relaciones, (a) Uno a varios, (b) Varios a uno. (c) Uno a uno. 


29 













































































FUNDAMENTOS DE BASES DE DATOS 



FIGURA 2.10. Diagrama E-R con un atributo unido a un conjunto de relaciones. 


tatario fuera varios a uno desde cliente a préstamo, 
entonces la línea desde prestatario a préstamo tendría 
una flecha apuntando al conjunto de entidades présta¬ 
mo (Figura 2.9b). Finalmente, si el conjunto de rela¬ 
ciones prestatario fuera uno a uno, entonces ambas lí¬ 
neas desde prestatario tendrían flechas: una apuntando 
al conjunto de entidades préstamo y otra apuntando al 
conjunto de entidades cliente (Figura 2.9c). 

Si un conjunto de relaciones tiene también algunos 
atributos asociados a él, entonces se unen esos atribu¬ 
tos a ese conjunto de relaciones. Por ejemplo, en la Figu¬ 
ra 2.10, se tiene el atributo descriptivo fecha-acceso uni¬ 
do al conjunto de relaciones impositor para especificar 
la fecha más reciente en la que un cliente accedió a esa 
cuenta. 

La Figura 2.11 muestra cómo se pueden representar 
atributos compuestos en la notación E-R. Aquí, el atri¬ 
buto compuesto nombre, con atributos componentes 
nombre-pila, primer-apellido y segundo-apellido reem¬ 
plaza al atributo simple nombre-cliente de cliente. Tam¬ 
bién se muestra el atributo compuesto dirección, cuyos 
atributos componentes son calle, ciudad, provincia y 
código-postal, que reemplaza a los atributos calle-clien¬ 
te y ciudad-cliente de cliente. El atributo calle es por si 


mismo un atributo compuesto cuyos atributos compo¬ 
nentes son número-calle, nombre-calle y número-piso. 

La Figura 2.11 también muestra un atributo multi- 
valorado, número-teléfono, indicado por una elipse 
doble, y un atributo derivado edad, indicado por una 
elipse discontinua. 

En los diagramas E-R se indican papeles mediante 
etiquetas en las líneas que unen rombos con rectángu¬ 
los. En la Figura 2.12 se muestran los indicadores de 
papeles director y trabajador entre el conjunto de enti¬ 
dades empleado y el conjunto de relaciones trabaja- 
par a. 

Los conjuntos de relaciones no binarias se pueden 
especificar fácilmente en un diagrama E-R. La Figura 
2.13 consta de tres conjuntos de entidades cliente, tra¬ 
bajo y sucursal, relacionados a través del conjunto de 
relaciones trabaja-en. 

Se pueden especificar algunos tipos de relaciones 
varios a uno en el caso de conjuntos de relaciones no 
binarias. Supóngase un empleado que tenga a lo sumo 
un trabajo en cada sucursal (por ejemplo, Santos no pue¬ 
de ser director y auditor en la misma sucursal). Esta res¬ 
tricción se puede especificar con una flecha apuntando 
a trabajo en el borde de trabaja-en. 



FIGURA 2.11. Diagrama E-R con atributos compuestos, multivalorados y derivados. 
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FIGURA 2.12. Diagrama E-R con indicadores de papeles. 


Se permite a lo sumo una flecha desde un conjunto 
de relaciones, ya que un diagrama E-R con dos o más 
flechas salientes de un conjunto de relaciones no bina¬ 
rias se puede interpretar de dos formas. Supónganse que 
hay un conjunto de relaciones R entre conjuntos de enti¬ 
dades Aj, A 2 ,... ,A„, y las únicas flechas están en los bor¬ 
des de los conjuntos de entidades A ;+1 , A ¡+1 ,... ,A n . Enton¬ 
ces, las dos posibles interpretaciones son: 

1. Una combinación particular de entidades de A,, 
A 2 ,...,A, se puede asociar con a lo sumo una 
combinación de entidades de A ¿+1 , A¡ +2 , ..., A n . 
Así, la clave primaria de la relación R se puede 
construir por la unión de las claves primarias de 
Aj, A 2 , ...,A¡. 

2. Para cada conjunto de entidades A k , i < k < = n, 
cada combinación de las entidades de los otros 
conjuntos de entidades se pueden asociar con a 
lo sumo una entidad de A k . Cada conjunto {A,, 
A 2 , . ..,A k _j, A k+] , A ¡+2 , .AJ, para i < k< = n, 
forma entonces una clave candidata. 

Cada una de estas interpretaciones se han usado en 
diferentes libros y sistemas. Para evitar confusión se 
permite sólo una flecha que salga de un conjunto de 
relaciones, y así las representaciones son equivalentes. 
En el Capítulo 7 (Apartado 7.3) se estudia la noción 
de dependencias funcionales, que permiten especifi¬ 
car cualquiera de estas dos interpretaciones sin ambi¬ 
güedad. 


En el diagrama E-R se usan las líneas dobles para 
indicar que la participación de un conjunto de entida¬ 
des en un conjunto de relaciones es total; es decir, cada 
entidad en el conjunto de entidades aparece al menos 
en una relación en ese conjunto de relaciones. Por ejem¬ 
plo, considérese la relación prestamista entre clientes y 
préstamos. Una línea doble de préstamo a prestamista, 
como en la Figura 2.14, indica que cada préstamo debe 
tener al menos un cliente asociado. 

Los diagramas E-R también proporcionan una for¬ 
ma de indicar restricciones más complejas sobre el 
número de veces en que cada entidad participa en las 
relaciones de un conjunto de relaciones. Un segmento 
entre un conjunto de entidades y un conjunto de rela¬ 
ciones binarias puede tener una cardinalidad mínima y 
máxima, mostrada de la forma mín.jnáx, donde mín es 
la mínima cardinalidad y máx es la máxima. Un valor 
mínimo de 1 indica una participación total del conjun¬ 
to de entidades en el conjunto de relaciones. Un valor 
máximo de 1 indica que la entidad participa de a lo sumo 
una relación, mientras que un valor máximo de * indi¬ 
ca que no hay límite. Nótese que una etiqueta 1..* en 
un segmento es equivalente a una línea doble. 

Por ejemplo, considérese la Figura 2.15. El segmento 
entre préstamo y prestamista tiene una restricción de 
cardinalidad de 1..1, significando que la cardinalidad 
mínima y máxima son ambas 1. Es decir, cada présta¬ 
mo debe tener exactamente un cliente asociado. El lími¬ 
te 0..* en el segmento de cliente a prestamista indica 
que un cliente puede tener ninguno o varios préstamos. 
Así, la relación prestamista es uno a varios de cliente a 
préstamo, y además la participación de préstamo en 
prestamista es total. 

Es fácil malinterpretar 0..* en el segmento entre clien¬ 
te y prestamista, y pensar que la relación prestamista 
es de varios a uno de cliente a préstamo —esto es exac¬ 
tamente lo contrario a la interpretación correcta. 

Si ambos segmentos de una relación binaria tienen 
un valor máximo de 1, la relación es uno a uno. Si se 
hubiese especificado un límite de cardinalidad de 1..* 
en el segmento entre cliente y prestamista, se estaría 
diciendo que cada cliente debe tener al menos un prés¬ 
tamo. 



FIGURA 2.13. Diagrama E-R con una relación ternaria. 
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FIGURA 2.14. Participación total de un conjunto de entidades en un conjunto de relaciones. 


2.6. CONJUNTOS DE ENTIDADES DÉBILES 


Un conjunto de entidades puede no tener suficientes atri¬ 
butos para formar una clave primaria. Tal conjunto de 
entidades se denomina conjunto de entidades débiles. 
Un conjunto de entidades que tiene una clave primaria 
se denomina conjunto de entidades fuertes. 

Como ilustración, considérese el conjunto de enti¬ 
dades pago, que tiene los tres atributos: número-pago, 
fecha-pago e importe-pago. Los números de pago son 
generalmente números secuenciales, empezando por 1, 
generados por separado por cada préstamo. Así, aunque 
cada entidad pago es distinta, los pagos para diferentes 
préstamos pueden compartir el mismo número de pago. 
Así, este conjunto de entidades no tiene una clave pri¬ 
maria; es un conjunto de entidades débiles. 

Para que un conjunto de entidades débiles tenga sen¬ 
tido, debe estar asociada con otro conjunto de entida¬ 
des, denominado el conjunto de entidades identifica- 
doras o propietarias. Cada entidad débil debe estar 
asociada con una entidad identificadora; es decir, se dice 
que el conjunto de entidades débiles depende existen- 
cialmente del conjunto de entidades identificadoras. Se 
dice que el conjunto de entidades identificadoras es pro¬ 
pietaria del conjunto de entidades débiles que identifi¬ 
ca. La relación que asocia el conjunto de entidades débi¬ 
les con el conjunto de entidades identificadoras se 
denomina relación identificadora. La relación identi¬ 
ficadora es varios a uno del conjunto de entidades débi¬ 
les al conjunto de entidades identificadoras y la partici¬ 
pación del conjunto de entidades débiles en la relación 
es total. 


En nuestro ejemplo, el conjunto de entidades iden- 
tificador para pago es préstamo, y la relación prés¬ 
tamo-pago que asocia las entidades pago con sus 
correspondientes entidades préstamo es la relación 
identificadora. 

Aunque un conjunto de entidades débiles no tiene 
clave primaria, no obstante se necesita conocer un 
medio para distinguir todas aquellas entidades del con¬ 
junto de entidades que dependen de una entidad fuer¬ 
te particular. El discriminante de un conjunto de enti¬ 
dades débiles es un conjunto de atributos que permite 
que esta distinción se haga. Por ejemplo, el discrimi¬ 
nante del conjunto de entidades débiles pago es el atri¬ 
buto número-pago, ya que, para cada préstamo, un 
número de pago identifica de forma única cada pago 
para ese préstamo. El discriminante de un conjunto de 
entidades débiles se denomina la clave parcial del con¬ 
junto de entidades. 

La clave primaria de un conjunto de entidades débi¬ 
les se forma con la clave primaria del conjunto de enti¬ 
dades identificadoras, más el discriminante del conjun¬ 
to de entidades débiles. En el caso del conjunto de 
entidades pago, su clave primaria es {número-présta¬ 
mo, número-pago}, donde número-préstamo es la cla¬ 
ve primaria del conjunto de entidades identificadoras, 
es decir, préstamo, y número-pago distingue las enti¬ 
dades pago dentro del mismo préstamo. 

El conjunto de entidades identificadoras no debería 
tener atributos descriptivos, ya que cualquier atributo 
requerido puede estar asociado con el conjunto de enti- 



FIGURA 2.15. Límites de cardinalidad en conjuntos de relaciones. 
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dades débiles (véase la discusión de trasladar los atri¬ 
butos del conjunto de relaciones a los conjuntos de enti¬ 
dades participantes en el Apartado 2.2.1). 

Un conjunto de entidades débiles puede participar 
en relaciones distintas de relaciones identificadoras. Por 
ejemplo, la entidad pago podría participar en una rela¬ 
ción con el conjunto de entidades con el conjunto de 
entidades cuenta, identificando la cuenta desde la que 
se realizó el pago. Un conjunto de entidades débiles pue¬ 
de participar como propietario en una relación identifi- 
cadora con otro conjunto de entidades débiles. También 
es posible tener un conjunto de entidades débiles con 
más de un conjunto de entidades identificadoras. Una 
entidad débil en concreto podría ser identificada por una 
combinación de entidades, una de cada conjunto de enti¬ 
dades identificadoras. La clave primaria de la entidad 
débil consistiría de la unión de las claves primarias de 
los conjuntos de entidades identificadoras más el dis¬ 
criminante del conjunto de entidades débiles. 

Un conjunto de entidades débiles se indica en los 
diagramas E-R mediante un rectángulo dibujado con 
una línea doble y la correspondiente relación de iden¬ 
tificación mediante un rombo dibujado con línea doble. 
En la Figura 2.16, el conjunto de entidades débiles pago 
es dependiente del conjunto de entidades fuertes prés¬ 
tamo a través del conjunto de relaciones pago-prés¬ 
tamo. 

La figura ilustra también el uso de líneas dobles para 
indicar participación total', la participación del conjun¬ 
to de entidades (débiles) pago en la relación pago-prés¬ 
tamo es total, significando que cada pago debe estar 
relacionando a través de pago-préstamo con alguna 


cuenta. Finalmente, la flecha desde pago-préstamo a 
préstamo indica que cada pago es para un único prés¬ 
tamo. El discriminante del conjunto de entidades débi¬ 
les también está subrayado, pero con un línea disconti¬ 
nua, en lugar de una continua. 

En algunos casos, el diseñador de la base de datos 
puede elegir expresar un conjunto de entidades débiles 
como un atributo compuesto multivalorado del conjunto 
de entidades propietarias. En el ejemplo, esta alternati¬ 
va requeriría que el conjunto de entidades préstamo 
tuviera un atributo compuesto y multivalorado pago, 
que constara de número-pago, fecha-pago e importe- 
pago. Un conjunto de entidades débiles se puede mode¬ 
lar más adecuadamente como un atributo si sólo parti¬ 
cipa en la relación identificadora y si tiene pocos 
atributos. Alternativamente, una representación de con¬ 
junto de entidades débiles será más adecuada para mode¬ 
lar una situación en la que el conjunto participe en otras 
relaciones además de la relación identificadora y don¬ 
de el conjunto de entidades débiles tenga muchos atri¬ 
butos. 

Como otro de un conjunto de entidades que se pue¬ 
de modelar como un conjunto de entidades débiles con¬ 
sidérense las ofertas de asignaturas en una universidad. 
La misma asignatura se puede ofrecer en diferentes cur¬ 
sos y dentro de un curso puede haber varios grupos para 
la misma asignatura. Así, se crea un conjunto de enti¬ 
dades débiles oferta-asignatura, que depende existen- 
cialmente de asignatura', las diferentes ofertas de la mis¬ 
ma asignatura se identifican por un curso y un 
número-grupo, que forma un discriminante pero no una 
clave primaria. 


2.7. CARACTERÍSITCAS DEL MODELO E-R EXTENDIDO 


Aunque los conceptos básicos de E-R pueden modelar 
la mayoría de las características de las bases de datos, 
algunos aspectos de una base de datos pueden ser más 
adecuadamente expresados mediante ciertas extensio¬ 


nes del modelo E-R básico. En este apartado se discu¬ 
ten las características E-R extendidas de especializa- 
ción, generalización, conjuntos de entidades de nivel 
más alto y más bajo, herencia de atributos y agregación. 



FIGURA 2.16. Diagrama E-R con un conjunto de entidades débiles. 
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2.7.1. Especialización 

Un conjunto de entidades puede incluir subgrupos de 
entidades que se diferencian de alguna forma de las otras 
entidades del conjunto. Por ejemplo, un subconjunto de 
entidades en un conjunto de entidades puede tener atri¬ 
butos que no son compartidos por todas las entidades 
del conjunto de entidades. El modelo E-R proporciona 
una forma de representación de estos grupos de entida¬ 
des distintos. 

Considérese el conjunto de entidades persona con 
atributos nombre, calle y ciudad. Una persona puede 
clasificarse además como: 

• cliente 

• empleado 

Cada uno de estos tipos de persona se describen 
mediante un conjunto de atributos que incluyen los atri¬ 
butos del conjunto de entidades persona más otros posi¬ 
bles atributos adicionales. Por ejemplo, las entidades 
cliente se pueden describir además mediante el atribu¬ 
to id-cliente, mientras que las entidades empleado se 
pueden describir además mediante los atributos id- 
empleado y sueldo. El proceso de designación de sub¬ 
grupos dentro de un conjunto de entidades se denomi¬ 
na especialización. La especialización de persona 
permite distinguir entre las personas basándose en si 
son empleados o clientes. 

Como otro ejemplo supóngase que el banco desea 
dividir las cuentas en dos categorías: cuentas corrien¬ 
tes y cuentas de ahorro. Las cuentas de ahorro necesi¬ 
tan un saldo mínimo, pero el banco establece diferen¬ 
tes tasas de interés a cada cliente, ofreciendo mejores 
tasas a los clientes favorecidos. Las cuentas corrientes 
tienen una tasa fija de interés, pero permiten los descu¬ 
biertos; el importe de descubierto de una cuenta corrien¬ 
te se debe registrar. 

El banco podría crear dos especializaciones de cuen¬ 
ta, denominadas cuenta-ahorro y cuenta-corriente. 
Como se vio anteriormente, las entidades cuenta se des¬ 
criben por los atributos número-cuenta y saldo. El con¬ 
junto de entidades cuenta-ahorro tendría todos los atri¬ 
butos de cuenta y un atributo adicional denominado 
tasa-interés. El conjunto de entidades cuenta-corrien¬ 
te tendría todos los atributos de cuenta y un atributo adi¬ 
cional importe-descubierto. 

Se puede aplicar repetidamente la especialización 
para refinar el esquema de diseño. Por ejemplo, los 
empleados del banco se pueden clasificar en uno de los 
siguientes: 

• oficial 

• cajero 

• secretaria 

Cada uno de estos tipos de empleado se describe por 
un conjunto de atributos que incluye todos los atribu¬ 


tos del conjunto de entidades empleado más otros adi¬ 
cionales. Por ejemplo, las entidades oficial se puede des¬ 
cribir por el atributo número-despacho, las entidades 
cajero por los atributos número-sección y horas-sema¬ 
na, y las entidades secretaria por el atributo horas-sema¬ 
na. Además, las entidades secretaria pueden participar 
en una relación secretaria-de, que identifica al empleado 
ayudado por una secretaria. 

Un conjunto de entidades se puede especializar por 
más de una característica distintiva. En el ejemplo, la 
característica distintiva entre entidades empleado es el 
trabajo que realiza el empleado. Otra especialización 
coexistente podría estar basada en si la persona es un 
trabajador temporal o fijo, resultado en los conjuntos de 
entidades empleado-temporal y empleado-fijo. Cuando 
se forma más de una especialización de un conjunto de 
entidades, una entidad en particular puede pertenecer a 
varias especializaciones. Por ejemplo, una empleada 
dada puede ser una empleada temporal y secretaria. 

En términos de un diagrama E-R, la especialización 
se representa mediante un componente triangular eti¬ 
quetado ES, como se muestra en la Figura 2.17. La eti¬ 
queta ES representa, por ejemplo, que un cliente «es» 
una persona. La relación ES se puede llamar también 
relación superclase-subclase. Los conjuntos de enti¬ 
dades de nivel más alto y más bajo se representan como 
conjuntos de entidades regulares, es decir, como rec¬ 
tángulos que contienen el nombre del conjunto de enti¬ 
dades. 

2.7.2. Generalización 

El refinamiento a partir de un conjunto de entidades 
inicial en sucesivos niveles de subgrupos de entida¬ 
des representa un proceso de diseño descendente en 
el que las distinciones se hacen explícitas. El proce¬ 
so de diseño puede ser también de una forma ascen¬ 
dente, en el que varios conjuntos de entidades se 
sintetizan en un conjunto de entidades de nivel más 
alto basado en características comunes. El diseñador 
de la base de datos puede haber identificado primero 
el conjunto de entidades cliente con los atributos nom¬ 
bre, calle, ciudad e id-cliente, y el conjunto de enti¬ 
dades empleado con los atributos nombre, calle, ciu¬ 
dad, id-empleado y sueldo. 

Hay similitudes entre el conjunto de entidades clien¬ 
te y el conjunto de entidades empleado en el sentido de 
que tienen varios atributos en común. Esta similitud se 
puede expresar mediante la generalización, que es una 
relación contenedora que existe entre el conjunto de enti¬ 
dades de nivel más alto y uno o más conjuntos de enti¬ 
dades de nivel más bajo. En el ejemplo, persona es el 
conjunto de entidades de nivel más alto y los conjuntos 
de entidades cliente y empleado son de nivel más bajo. 
Los conjuntos de entidades de nivel más alto y nivel más 
bajo también se pueden llamar superclase y subclase, 
respectivamente. El conjunto de entidades persona es la 
superclase de las subclases cliente y empleado. 
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FIGURA 2.17. Especialización y generalización. 


Para todos los propósitos prácticos, la generalización 
es una inversión simple de la especialización. Se apli¬ 
carán ambos procesos en combinación en el curso del 
diseño del esquema E-R para una empresa. En térmi¬ 
nos del propio diagrama E-R no se distingue entre espe¬ 
cialización y generalización. Los niveles nuevos de 
representación de entidades serán distinguidos (es¬ 
pecialización) o sintetizados (generalización) cuando 
el esquema de diseño llegue a expresar completamente 
la aplicación de base de datos y los requisitos de uso de 
la base de datos. Las diferencias entre los dos enfoques 
se pueden caracterizar mediante su punto de partida y 
el objetivo global. 

La especialización parte de un conjunto de entida¬ 
des simple; enfatiza las diferencias entre las entida¬ 
des dentro del conjunto mediante la creación de dis¬ 
tintos conjuntos de entidades de nivel más bajo. Estos 
conjuntos de entidades de nivel más bajo pueden tener 
atributos, o pueden participar en relaciones que no se 
aplican a todas las entidades del conjunto de entida¬ 
des de nivel más alto. Realmente, la razón de que el 
diseñador aplique la especialización es representar 
tales características diferentes. Si cliente y empleado 
no tuvieran cada una atributos únicos que no tuvieran 
las entidades persona en la que participan, no habría 
necesidad de especializar el conjunto de entidades per¬ 
sona. 


La generalización procede de observar que varios 
conjuntos de entidades que comparten algunas caracte¬ 
rísticas comunes (se describen mediante los mismos atri¬ 
butos y participan en los mismos conjuntos de relacio¬ 
nes). Basada en sus similitudes, la generalización sintetiza 
estos conjuntos de entidades en uno solo, el conjunto de 
entidades de nivel más alto. La generalización se usa 
para resaltar las similitudes entre los conjuntos de enti¬ 
dades de nivel más bajo y para ocultar las diferencias; 
también permite economizar la representación para que 
los atributos compartidos no estén repetidos. 

2.7.3. Herencia de atributos 

Una propiedad crucial de las entidades de nivel más alto 
y más bajo creadas mediante especialización y genera¬ 
lización es la herencia de atributos. Los atributos de 
los conjuntos de entidades de nivel más alto se dice que 
son heredados por los conjuntos de entidades de nivel 
más bajo. Por ejemplo, cliente y empleado heredan los 
atributos de persona. Así, cliente se describe mediante 
sus atributos nombre, calle y ciudad y adicionalmente 
por el atributo id-cliente ; empleado se describe median¬ 
te sus atributos nombre, calle y ciudad y adicionalmente 
por los atributos id-empleado y sueldo. 

Un conjunto de entidades de nivel más bajo (o sub¬ 
clase) también hereda la participación en los conjuntos 


35 

































FUNDAMENTOS DE BASES DE DATOS 


de relaciones en los que su entidad de nivel más alto (o 
superclase) participa. Ambos conjuntos de entidades ofi¬ 
cial, cajero y secretaria participan en el conjunto de 
relaciones trabaja-para. La herencia de atributos se apli¬ 
ca en todas las capas de los conjuntos de entidades de 
nivel más bajo. Los conjuntos de entidades anteriores 
pueden participar cualquier relación en que participe el 
conjunto de entidades persona. 

Si se llega a una porción dada de un modelo E-R 
mediante especialización o generalización, el resultado 
es básicamente el mismo: 

• Un conjunto de entidades de nivel más alto con 
atributos y relaciones que se aplican a todos los 
conjuntos de entidades de nivel más bajo. 

• Conjuntos de entidades de nivel más bajo con 
características distintivas que se aplican sólo en un 
conjunto de entidades particular. 

En lo que sigue, aunque a menudo se hará referen¬ 
cia sólo a la generalización, las propiedades que se dis¬ 
cuten pertenecen a ambos procesos. 

En la Figura 2.17 se describe una jerarquía de con¬ 
juntos de entidades. En la figura, empleado es un con¬ 
junto de entidades de nivel más bajo de persona y un 
conjunto de entidades de nivel más alto de los conjun¬ 
tos de entidades oficial, cajero y secretaria. En una jerar¬ 
quía, un conjunto de entidades dado puede estar impli¬ 
cado como un conjunto de entidades de nivel más bajo 
sólo en una única relación ES. Si un conjunto de enti¬ 
dades es un conjunto de entidades de nivel más bajo en 
más de una relación ES, entonces el conjunto de enti¬ 
dades tiene herencia múltiple, y la estructura resultante 
se denomina retículo. 

2.7.4. Restricciones sobre las generalizaciones 

Para modelar una empresa más exactamente, el diseña¬ 
dor de la base de datos puede elegir colocar ciertas res¬ 
tricciones en una generalización particular. Un tipo de 
restricción implica determinar qué entidades pueden ser 
miembros de un conjunto de entidades de nivel más bajo 
dado. Tales relaciones de miembros pueden ser algunas 
de los siguientes: 

• Definido por condición. En los conjuntos de enti¬ 
dades de nivel más bajo, la relación miembro se 
evalúa en función de si una entidad satisface o no 
una condición explícita o predicado. Por ejemplo, 
asúmase que el conjunto de entidades de nivel más 
alto cuenta tiene el atributo tipo-cuenta. Todas las 
entidades cuenta se evalúan según la definición del 
atributo tipo-cuenta. Sólo aquellas entidades que 
satisfagan la condición tipo-cuenta = «cuenta de 
ahorro» podrán pertenecer al conjunto de entida¬ 
des de nivel más bajo cuenta-ahorro. Todas las 
entidades que satisfagan la condición tipo-cuenta 
= «cuenta corriente» estarán incluidas en cuenta- 


corriente. Como todas las entidades de nivel más 
bajo se evalúan en función del mismo atributo (en 
este caso, tipo-cuenta), este tipo de generalización 
se denomina definido por atributo. 

• Definido por el usuario. Los conjuntos de enti¬ 
dades de nivel más bajo definidos por el usuario 
no están restringidos mediante una condición de 
miembro; en cambio, las entidades se asignan a un 
conjunto de entidades dado por el usuario de la 
base de datos. Por ejemplo, asúmase que, después 
de tres meses de empleo, se asignan los emplea¬ 
dos del banco a uno de los cuatro grupos de tra¬ 
bajo. Los grupos se representan, por tanto, como 
cuatro conjuntos de entidades de nivel más bajo 
del conjunto de entidades de nivel más alto emple¬ 
ado. Un empleado dado no se asigna a una enti¬ 
dad grupo automáticamente en términos de una 
condición que lo defina explícitamente. En su lugar, 
la asignación al grupo se hace de forma individual 
por el usuario a cargo de la decisión. Las asigna¬ 
ción se implementa mediante una operación que 
añade una entidad a un conjunto de entidades. 

Un segundo tipo de restricciones se define según si 
las entidades pueden pertenecer a más de un conjunto 
de entidades de nivel más bajo en una generalización 
simple. Los conjuntos de entidades de nivel más bajo 
pueden ser uno de los siguientes: 

• Dísjunto. Una restricción sobre el carácter dis¬ 
junto requiere que una entidad no pertenezca a más 
de un conjunto de entidades de nivel más bajo. En 
el ejemplo, una entidad cuenta puede satisfacer 
sólo una condición para el atributo tipo-cuenta; 
una entidad puede ser bien una cuenta de ahorro o 
bien una cuenta corriente, pero no ambas cosas a 
la vez. 

• Solapado. En las generalizaciones solapadas, la 
misma entidad puede pertenecer a más de un con¬ 
junto de entidades de nivel más bajo en una gene¬ 
ralización simple. Como ilustración, tomando el 
ejemplo del grupo de trabajo del empleado, asú¬ 
mase que ciertos directores participen en más de 
un grupo de trabajo. Un empleado dado puede, por 
lo tanto, aparecer en más de uno de los conjuntos 
de entidades grupo que son conjuntos de entida¬ 
des de nivel más bajo de empleado. Así, la gene¬ 
ralización es solapada. 

Como otro ejemplo, supóngase la generaliza¬ 
ción aplicada a los conjuntos de entidades cliente 
y empleado conduce a un conjunto de entidades 
de nivel más alto persona. La generalización está 
solapada si un empleado también puede ser un 
cliente. 

La entidad de nivel más bajo solapada es el caso 
predeterminado; la restricción sobre el carácter dis¬ 
junto se debe colocar explícitamente en una generali- 
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zación (o especialización). Se puede identificar una 
restricción sobre el carácter disjunto en un diagrama 
E-R añadiendo la palabra disjunto en el símbolo del 
triángulo. 

Una restricción final, la restricción de completitud 
en una generalización o especialización, especifica si 
un conjunto de entidades de nivel más alto debe perte¬ 
necer o no a al menos a uno de los conjuntos de enti¬ 
dades de nivel más bajo en una generalización/espe- 
cialización. Esta restricción puede ser una de las 
siguientes: 

• Generalización o especialización total. Cada enti¬ 
dad de nivel más alto debe pertenecer a un con¬ 
junto de entidades de nivel más bajo. 

• Generalización o especialización parcial. Algu¬ 
nas entidades de nivel más alto pueden no perte¬ 
necer a algún conjunto de entidades de nivel más 
bajo. 

La generalización parcial es la predeterminada. Se 
puede especificar una generalización total en un dia¬ 
grama E-R usando una línea doble para conectar el rec¬ 
tángulo que representa el conjunto de entidades de nivel 
más alto con el símbolo del triángulo (esta notación es 
similar a la notación de participación total en una rela¬ 
ción). 

La generalización de cuenta es total: todas las enti¬ 
dades cuenta deben ser o bien cuentas de ahorro o bien 
cuentas corrientes. Debido a que el conjunto de enti¬ 
dades de nivel más alto alcanzado a través de la gene¬ 
ralización está generalmente compuesta únicamente 
por aquellas entidades del conjunto de entidades de 
nivel más bajo, la restricción de completitud para un 
conjunto de entidades de nivel más alto generalizado 
es habitualmente total. Cuando la restricción es parcial, 
la entidad de nivel más alto no aparece necesariamente 
en el conjunto de entidades de nivel más bajo. Los con¬ 
juntos de entidades grupo de trabajo ilustran una espe¬ 
cialización parcial. Como los empleados se asignan a 
grupos sólo después de llevar tres meses en el trabajo, 
algunas entidades empleado pueden no ser miembros 
de ningún conjunto de entidades grupo de nivel más 
bajo. 

Los conjuntos de entidades equipo se pueden carac¬ 
terizar más completamente como una especialización 
de empleado parcial y solapada. La generalización de 
cuenta-corriente y cuenta-ahorro en cuenta es una 
generalización total y disjunta. Las restricciones de 
completitud y sobre el carácter disjunto, sin embargo, 
no dependen una de la otra. Los patrones de restric¬ 
ciones pueden ser también parcial-disjunta y total-sola¬ 
pada. 

Se puede ver que ciertos requisitos de inserción y 
borrado son consecuencia de las restricciones que se 
aplican a una generalización o especialización dada. Por 
ejemplo, cuando se coloca una restricción de completi¬ 
tud total, una entidad insertada en un conjunto de enti¬ 


dades de nivel más alto se debe insertar en al menos uno 
de los conjuntos de entidades de nivel más bajo. Con 
una restricción de definición por condición, todas las 
entidades de nivel más alto que satisfacen la condición 
se deben insertar en el conjunto de entidades de nivel 
más bajo. Linalmente, una entidad que se borra de un 
conjunto de entidades de nivel más alto, también se debe 
borrar de todos los conjuntos de entidades de nivel más 
bajo asociados a los que pertenezca. 

2.7.5. Agregación 

Una limitación del modelo E-R es que no resulta posi¬ 
ble expresar relaciones entre relaciones. Para ilustrar la 
necesidad de tales construcciones considérese la rela¬ 
ción ternaria trabaja-en, que se vio anteriormente, entre 
empleado, sucursal y trabajo (véase la Ligura 2.13). 
Supóngase ahora que se desean registrar los directores 
para las tareas realizadas por un empleado en una sucur¬ 
sal; es decir, se desean registrar directores por combi¬ 
naciones ( empleado, sucursal, trabajo). Asúmase que 
existe una entidad director. 

Una alternativa para representar esta relación es crear 
una relación cuaternaria dirige entre empleado, sucur¬ 
sal, trabajo y director (se necesita una relación cuater¬ 
naria; una relación binaria entre director y empleado no 
permitiría representar las combinaciones [sucursal, 
trabajo] de un empleado que están dirigidas por un 
director). Al usar los constructores básicos del modela¬ 
do E-R se obtiene el diagrama E-R de la Ligura 2.18 
(por simplicidad se han omitido los atributos). 

Parece que los conjuntos de relaciones trabaja-en y 
dirige se pueden combinar en un único conjunto de rela¬ 
ciones. No obstante, no se deberían combinar, dado que 
algunas combinaciones empleado, sucursal, trabajo 
puede que no tengan director. 

Hay información redundante en la figura resultante, 
ya que cada combinación empleado, sucursal, trabajo 
en dirige también lo está en trabaja-en. Si el director 
fuese un valor en lugar de una entidad director, se podría 
hacer que director fuese un atributo multivalorado de 
la relación trabaja-en. Pero esto implica que es más difí¬ 
cil (tanto lógicamente como en coste de ejecución) 
encontrar, por ejemplo, los triples empleado-sucursal- 
trabajo de los que un director es responsable. Como el 
director es una entidad director, se descarta esta alter¬ 
nativa en cualquier caso. 

La mejor forma de modelar una situación como ésta 
es usar la agregación. La agregación es una abstracción 
a través de la cual las relaciones se tratan como entida¬ 
des de nivel más alto. Así, para este ejemplo, se consi¬ 
dera el conjunto de relaciones trabaja-en (que relacio¬ 
na los conjuntos de entidades empleado, sucursal y 
trabajo ) como un conjunto de entidades de nivel más 
alto denominado trabaja-en. Tal conjunto de entidades 
se trata de la misma forma que cualquier otro conjunto 
de entidades. Se puede crear entonces una relación bina¬ 
ria dirige entre trabaja-en y director para representar 
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FIGURA 2.18. Diagrama E-R con relaciones redundantes. 


quién dirige las tareas. En la Figura 2.19 se muestra una 
notación para la agregación que se usa habitualmente 
para esta situación. 

2.7.6. Notaciones E-R alternativas 

La Figura 2.20 resume el conjunto de símbolos que 
hemos usado en los diagramas E-R. No hay ningún están¬ 
dar universal para la notación de los diagramas E-R y 
diferentes libros y diferente software de diagramas E-R 
usan notaciones diferentes; la Figura 2.21 indica alguna 
de las notaciones alternativas que se usan ampliamente. 
Un conjunto de entidades se puede representar como un 
cuadro con el nombre fuera, y los atributos listados unos 


debajo de otros dentro del cuadro. Los atributos clave 
primaria se indican listándolos en la parte superior, con 
una línea separándolos de los otros atributos. 

Las restricciones de cardinalidad se pueden indicar 
de varias formas como se muestra en la Figura 2.21. Las 
etiquetas * y 1 en los arcos que salen de las relaciones 
se usan a menudo para denotar relaciones varios a varios, 
uno a uno y varios a uno como se muestra en la figura. 
En otra notación alternativa de la figura los conjuntos 
de relaciones se representan por líneas entre conjuntos 
de entidades sin rombos; sólo se pueden modelar de esta 
forma las relaciones binarias. Las restricciones de car¬ 
dinalidad en esta notación se muestran por la notación 
«pata de gallo», como en la figura. 



FIGURA 2.19. Diagrama E-R con agregación. 


38 
































CAPÍTULO 2 MODELO ENTIDAD-RELACIÓN 


E 


conjunto de entidades 


atributo 


conjunto de entidades 
débiles 



atributo 

multivalorado 



conjunto de relaciones 



atributo derivado 



conjunto de relaciones 
identificador de un 
conjunto de entidades 
débiles 



partipación total del 
conjunto de entidades 
en la relación 



clave primaria 



atributo discriminador 
de un conjunto de 
entidades débiles 




nombre 
de papel 



relación varios 
a varios 


relación uno 
a uno 


indicador de papel 



relación varios a uno 


límites de cardinalidad 


ES 

(especialización 
o generalización) 



generalización total 


FIGURA 2.20. S ímbolos usados en la notación E-R. 



generalización 

disjunta 


2.8. DISEÑO DE UN ESQUEMA DE BASE DE DATOS E-R 


El modelo de datos E-R da una flexibilidad sustancial 
en el diseño de un esquema de bases de datos para mode¬ 
lar una empresa dada. En este apartado se considera 
cómo un diseñador de bases de datos puede seleccionar 
entre el amplio rango de alternativas. Entre las decisio¬ 
nes que se toman están las siguientes: 

• Si se usa un atributo o un conjunto de entidades 
para representa un objeto (discutido anteriormen¬ 
te en el Apartado 2.2.1) 

• Si un concepto del mundo real se expresa más exac¬ 
tamente mediante un conjunto de entidades o me¬ 
diante un conjunto de relaciones (Apartado 2.2.2) 

• Si se usa una relación ternaria o un par de relacio¬ 
nes binaras (Apartado 2.2.3) 


• Si se usa un conjunto de entidades fuertes o débi¬ 
les (Apartado 2.6); un conjunto de entidades fuer¬ 
tes y sus conjuntos de entidades débiles depen¬ 
dientes se pueden considerar como un «objeto» en 
la base de datos, debido a que la existencia de las 
entidades débiles depende de la entidad fuerte 

• Si el uso de la generalización (Apartado 2.7.2) es 
apropiado; la generalización, o una jerarquía de 
relaciones ES, contribuye a la modularidad por 
permitir que los atributos comunes de conjuntos 
de entidades similares se representen en un único 
lugar en un diagrama E-R 

• Si el uso de la agregación (Apartado 2.7.5) es apro¬ 
piado; la agregación agrupa una parte de un dia- 
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E 


conjunto de entidades E 
con atributos Al, A2 y A3, 
y clave primaria Al 


relación varios a varios 


relación uno a uno 


relación varios a uno 



FIGURA 2.21. Notaciones E-R alternativas. 


grama E-R en un único conjunto de entidades, per¬ 
mitiendo tratar el conjunto de entidades de la agre¬ 
gación como una unidad única sin importar los 
detalles de su estructura interna. 

Se verá que el diseñador de bases de datos necesita 
un buen entendimiento de la empresa que se modela 
para tomar estas decisiones. 

2.8.1. Fases de diseño 

Un modelo de datos de alto nivel sirve al diseñador de 
la base de datos para proporcionar un marco conceptual 
en el que especificar de forma sistemática los requisi¬ 
tos de datos de los usuarios de la base de datos que exis¬ 
ten, y cómo se estructurará la base de datos para com¬ 
pletar estos requisitos. La fase inicial del diseño de bases 
de datos, por tanto, es caracterizar completamente las 
necesidades de datos esperadas por los usuarios de la 
base de datos. El resultado de esta fase es una especifi¬ 
cación de requisitos del usuario. 

A continuación, el diseñador elige un modelo de datos 
y, aplicando los conceptos del modelo de datos elegido, 
traduce estos requisitos a un esquema conceptual de la 
base de datos. El esquema desarrollado en esta fase de 
diseño conceptual proporciona una visión detallada del 
desarrollo. Debido a que sólo se ha estudiado el modelo 
E-R hasta ahora, se usará éste para desarrollar el esque¬ 
ma conceptual. En términos del modelo E-R, el esquema 
especifica todos los conjuntos de entidades, conjuntos de 
relaciones, atributos y restricciones de correspondencia. 
El diseñador revisa el esquema para confirmar que todos 
los requisitos de datos se satisfacen realmente y no hay 
conflictos entre sí. También se examina el diseño para eli¬ 


minar características redundantes. Lo importante en este 
punto es describir los datos y las relaciones, más que espe¬ 
cificar detalles del almacenamiento físico. 

Un esquema conceptual completamente desarrolla¬ 
do indicará también los requisitos funcionales de la 
empresa. En una especificación de requisitos funcio¬ 
nales los usuarios describen los tipos de operaciones (o 
transacciones) que se realizarán sobre los datos. Algu¬ 
nos ejemplos de operaciones son la modificación o 
actualización de datos, la búsqueda y recuperación de 
datos específicos y el borrado de datos. En esta fase de 
diseño conceptual se puede hacer una revisión del esque¬ 
ma para encontrar los requisitos funcionales. 

El proceso de trasladar un modelo abstracto de datos 
a la implementación de la base de datos consta de dos 
fases de diseño finales. En la fase de diseño lógico, el 
diseñador traduce el esquema conceptual de alto nivel 
al modelo de datos de la implementación del sistema de 
base de datos que se usará. El diseñador usa el esque¬ 
ma resultante específico a la base de datos en la siguien¬ 
te fase de diseño físico, en la que se especifican las 
características físicas de la base de datos. Estas carac¬ 
terísticas incluyen la forma de organización de los archi¬ 
vos y las estructuras de almacenamiento interno, que se 
discutirán en el Capítulo 11. 

En este capítulo se tratan sólo los conceptos del 
modelo E-R usados en la fase de diseño del esquema 
conceptual. Se ha presentado una breve visión del pro¬ 
ceso de diseño de bases de datos para proporcionar un 
contexto para la discusión del modelo de datos E-R. El 
diseño de bases de datos recibe un tratamiento comple¬ 
to en el Capítulo 7. 

En el Apartado 2.8.2 se aplican las dos fases inicia¬ 
les de diseño de bases de datos al ejemplo del banco. 
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Se emplea el modelo de datos E-R para traducir los 
requisitos de usuario al esquema de diseño conceptual 
que se describe como un diagrama E-R. 

2.8.2. Diseño de base de datos para el banco 

Nos centramos ahora en los requisitos de diseño de la 
base de datos para el banco en más detalle y desarro¬ 
llamos un diseño más realista, aunque también más com¬ 
plicado, de lo que se ha visto en los ejemplos anterio¬ 
res. Sin embargo, no se intentará modelar cada aspecto 
del diseño de la base de datos para un banco; se consi¬ 
derarán sólo unos cuantos aspectos para ilustrar el pro¬ 
ceso de diseño de bases de datos. 

2.8.2.I. Requisitos de datos 

La especificación inicial de los requisitos de usuario se 
puede basar en entrevistas con los usuarios de la base 
de datos y en el análisis propio del diseñador del desa¬ 
rrollo. La descripción que surge de esta fase de diseño 
sirve como base para especificar la estructura concep¬ 
tual de la base de datos. La siguiente lista describe los 
principales requisitos del banco: 

• El banco está organizado en sucursales. Cada 
sucursal está ubicada en una ciudad particular y se 
identifica por un nombre único. El banco supervi¬ 
sa los activos de cada sucursal. 

• Los clientes del banco se identifican mediante sus 
valores de id-cliente. El banco almacena cada nom¬ 
bre de cliente, y la calle y ciudad donde viven los 
clientes. Los clientes pueden tener cuentas y pue¬ 
den pedir préstamos. Un cliente puede estar aso¬ 
ciado con un banquero particular, que puede actuar 
como responsable de préstamos o banquero perso¬ 
nal para un cliente. 

• Los empleados del banco se identifican mediante 
sus valores de id-empleado. La administración del 
banco almacena el nombre y número de teléfono 
de cada empleado, los nombres de los subordi¬ 
nados del empleado, y el número id-empleado del 
jefe del empleado. El banco también mantiene 
registro de la fecha de comienzo del contrato del 
empleado, así como su antigüedad. 

• El banco ofrece dos tipos de cuentas: cuentas de 
ahorro y cuentas corrientes. Las cuentas pueden 
asociarse a más de un cliente y un cliente puede 
tener más de una cuenta. Cada cuenta está asigna¬ 
da a un único número de cuenta. El banco man¬ 
tiene un registro del saldo de cada cuenta y la fecha 
más reciente en que la cuenta fue accedida por cada 
cliente que mantiene la cuenta. Además, cada cuen¬ 
ta de ahorro tiene un tipo de interés y para cada 
cuenta corriente se almacena el descubierto. 

• Un préstamo tiene lugar en una sucursal particu¬ 
lar y puede estar asociado a uno o más clientes. Un 
préstamo se identifica mediante un único número 


de préstamo. Para cada préstamo el banco man¬ 
tiene registro del importe del préstamo y de los 
pagos del préstamo. Aunque un número de pago 
del préstamo no identifica de forma única un pago 
entre todos los préstamos del banco, un número de 
pago identifica un pago particular para un présta¬ 
mo específico. Para cada pago se almacenan la 
fecha y el importe. 

En un desarrollo de un banco real, el banco manten¬ 
dría información de los abonos y cargos en las cuentas 
de ahorros y en las cuentas corrientes, igual que se man¬ 
tiene registro de los pagos para los préstamos. Debido 
a que los requisitos del modelo para este seguimiento 
son similares, y para mantener nuestro ejemplo reduci¬ 
do, en este modelo no se mantiene un seguimiento de 
tales abonos y cargos. 

2.8.2.2. Designación de los conjuntos 
de entidades 

La especificación de los requisitos de datos sirve como 
punto de partida para la construcción de un esquema 
conceptual para la base de datos. Desde la especifica¬ 
ción listada en el Apartado 2.8.2.1 se comienzan a iden¬ 
tificar los conjuntos de entidades y sus atributos. 

• El conjunto de entidades sucursal, con los atribu¬ 
tos nombre-sucursal, ciudad-sucursal y activo. 

• El conjunto de entidades cliente, con los atributos 
id-cliente, nombre-cliente, calle-cliente y ciudad- 
cliente. Un posible atributo adicional es nombre- 
banquero. 

• El conjunto de entidades empleado, con los atri¬ 
butos id-empleado, nombre-empleado, número- 
teléfono, sueldo y jefe. Algunas características des¬ 
criptivas adicionales son el atributo multivalorado 
nombre-subordinado, el atributo base fecha- 
comienzo y el atributo derivado antigüedad. 

• Dos conjuntos de entidades cuenta -cuenta-aho¬ 
rro y cuenta-corriente— con los atributos comu¬ 
nes número-cuenta y saldo', además, cuenta-aho¬ 
rro tiene el atributo tipo-interés y cuenta-corriente 
tiene el atributo descubierto. 

• El conjunto de entidades préstamo, con los atribu¬ 
tos número-préstamo, importe y sucursal-origen. 

• El conjunto de entidades débiles pago-préstamo, 
con los atributos número-pago, fecha-pago e 
importe-pago. 

2.8.2.3. Designación de los conjuntos 
de relaciones 

Volviendo ahora al esquema de diseño rudimentario del 
Apartado 2.8.2.2 se especifican los siguientes conjun¬ 
tos de relaciones y correspondencia de cardinalidades: 

• prestatario, un conjunto de relaciones varios a 
varios entre cliente y préstamo. 
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• préstamo-sucursal, un conjunto de relaciones 
varios a uno que indica la sucursal en que se ha 
originado un préstamo. Nótese que este conjunto 
de relaciones reemplaza al atributo sucursal-ori¬ 
gen del conjunto de entidades préstamo. 

• pago-préstamo, un conjunto de relaciones uno a 
varios de préstamo a pago, que documenta que se 
ha realizado un pago de un préstamo. 

• impositor, con el atributo de relación fecha-acce¬ 
so, un conjunto de relaciones varios a varios entre 
cliente y cuenta, indicando que un cliente posee 
una cuenta. 

• banquero-consejero, con el atributo de relación 
tipo, un conjunto de relaciones varios a uno que 
expresa que un cliente puede ser aconsejado por 
un empleado del banco, y que un empleado del 


banco puede aconsejar a uno o más clientes. Nóte¬ 
se que este conjunto de relaciones ha reemplaza¬ 
do al atributo nombre-banquero del conjunto de 
entidades cliente. 

• trabaja-para, un conjunto de relaciones entre enti¬ 
dades empleado con papeles que indican jefe y tra¬ 
bajador, la correspondencia de cardinalidades 
expresa que un empleado trabaja para un único 
jefe, y que un jefe supervisa uno o más emplea¬ 
dos. Nótese que este conjunto de relaciones reem¬ 
plaza el atributo jefe de empleado. 

2.8.2.4. Diagrama E-E 

Conforme a lo discutido en el Apartado 2.8.2.3 se pre¬ 
senta ahora el diagrama E-R completo para el ejemplo 
del banco. En la Figura 2.22 se muestra la representación 
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completa de un modelo conceptual de un banco, expre¬ 
sada en términos de los conceptos E-R. El diagrama inclu¬ 
ye los conjuntos de entidades, atributos, conjuntos de 


relaciones, y correspondencia de cardinalidades alcan¬ 
zados a través del proceso de diseño de los Apartados 
2.8.2.1 y 2.8.2.2, y refinados en el Apartado 2.8.2.3. 


2.9. REDUCCIÓN DE UN ESQUEMA E-R A TABLAS 


Una base de datos que se ajusta a un esquema de ba¬ 
ses de datos E-R se puede representar por una colec¬ 
ción de tablas. Para cada conjunto de entidades de 
la base de datos y para cada conjunto de relaciones de la 
base de datos hay una única tabla a la que se asigna el 
nombre del conjunto de entidades o del conjunto de rela¬ 
ciones correspondiente. Cada tabla tiene varias colum¬ 
nas, cada una de las cuales tiene un nombre único. 

Los modelos E-R y el de bases de datos relacióna¬ 
les son representaciones abstractas y lógicas de empre¬ 
sas del mundo real. Debido a que los dos modelos 
emplean principios de diseño similares, se puede con¬ 
vertir un diseño E-R en un diseño relacional. Convertir 
una representación de bases de datos de un diagrama 
E-R a un formato de tablas es la base para la derivación 
de un diseño de bases de datos relacional desde un dia¬ 
grama E-R. Aunque existen diferencias importantes 
entre una relación y una tabla, una relación se puede 
considerar informalmente como una tabla de valores. 

En este apartado se describe cómo se puede repre¬ 
sentar un esquema E-R mediante tablas; y en el Capí¬ 
tulo 3 se muestra cómo generar un esquema de bases de 
datos relacional a partir de un esquema E-R. 

Las restricciones especificadas en un diagrama E-R, 
tales como las claves primarias y las restricciones de 
cardinalidad, se corresponden con restricciones sobre 
las tablas generadas a partir del diagrama E-R. Se pro¬ 
porcionan más detalles sobre esta correspondencia en 
el Capítulo 6 después de describir cómo especificar res¬ 
tricciones sobre tablas. 

2.9.1. Representación tabular de los conjuntos 
de entidades fuertes 

Sea E un conjunto de entidades fuertes con los atribu¬ 
tos descriptivos a v a 2 , ...,a n . Esta entidad se represen¬ 
ta mediante una tabla llamada E con n columnas dis¬ 
tintas, cada una de las cuales corresponde a uno de los 
atributos de E. Cada fila de la tabla corresponde a una 
entidad del conjunto de entidades E. (En los apartados 
2.9.4 y 2.9.5 se describe cómo manjear los atributos 
compuestos y multivalorados.) 

Como ilustración considérese el conjunto de entida¬ 
des préstamo del diagrama E-R mostrado en la Figura 
2.8. Este conjunto de entidades tiene dos atributos: núme¬ 
ro-préstamo e importe. Se representa este conjunto de 
entidades mediante una tabla llamada préstamo , con dos 
columnas, como se muestra en la Figura 2.23. La fila 

(P-17,1.000) 


número-préstamo 

importe 

P-11 

900 

P-14 

1.500 

P-15 

1.500 

P-16 

1.300 

P-17 

1.000 

P-23 

2.000 

P-93 

500 


FIGURA 2.23. La tabla préstamo. 


de la tabla préstamo significa que el número de présta¬ 
mo P-17 tiene un importe de préstamo de 1.000 €. Se 
puede añadir una nueva entidad a la base de datos inser¬ 
tando una fila en una tabla. También se pueden borrar 
o modificar las filas. 

D, denota el conjunto de todos los números de prés¬ 
tamo y D 2 denota el conjunto de todos los saldos. Cual¬ 
quier fila de la tabla préstamo debe consistir en una tupia 
(v 1; v 2 ), donde v, es un número de préstamo (es decir, y, 
está en el conjunto D { ) y v 2 es un importe (es decir, v 2 
está en el conjunto D 2 ). En general, la tabla préstamo con¬ 
tendrá sólo un subconjunto del conjunto de todas las filas 
posibles. El conjunto de todas las filas posibles de prés¬ 
tamo es el producto cartesiano de D , y D 2 , denotado por 

x D 2 

En general, si se tiene una tabla de n columnas, se 
denota el producto cartesiano de D,, D 2 ,.. ,,D n por 

D l xD 2 x ... x D nA x D n 

Como otro ejemplo considérese el conjunto de enti¬ 
dades cliente del diagrama E-R mostrado en la Figura 
2.8. Este conjunto de entidades tiene los atributos id- 
cliente, nombre-cliente, calle-cliente y ciudad-cliente. 
La tabla correspondiente a cliente tiene cuatro colum¬ 
nas, como se muestra en la Figura 2.24. 

2.9.2. Representación tabular de los conjuntos 
de entidades débiles 

Sea A un conjunto de entidades débiles con los atribu¬ 
tos a v a 2 ,...,a m . Sea B el conjunto de entidades fuertes 
del que A depende. Sea la clave primaria de B el con¬ 
junto de atributos b v b 2 ,..., b n . Se representa el conjun¬ 
to de entidades A mediante una tabla llamada A con una 
columna por cada uno de los atributos del conjunto: 
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id-cliente 

nombre-cliente 

calle-cliente 

ciudad-cliente 

01.928.374 

18.273.609 

19.283.746 

24.466.880 

32.112.312 

33.557.799 

33.666.999 

67.789.901 

96.396.396 

Gómez 

Abril 

González 

Pérez 

Santos 

Fernández 

Rupérez 

López 

Valdivieso 

Carretas 

Preciados 

Arenal 

Carretas 

Mayor 

Jazmín 

Ramblas 

Mayor 

Goya 

Cerceda 

Valsaín 

La Granja 

Cerceda 

Peguerinos 

León 

León 

Peguerinos 

Vigo 


FIGURA 2.24. La tabla cliente. 


{a v a 2 ,...,a m } U {b { , b 2 ,...,b n } 

Como ilustración considérese el conjunto de entida¬ 
des pago mostrado en el diagrama E-R de la Figura 2.16. 
Este conjunto de entidades tiene tres atributos: núme¬ 
ro-pago, fecha-pago e importe-pago. La clave prima¬ 
ria del conjunto de entidades préstamo, de la que pago 
depende, es número-préstamo. Así, pago se representa 
mediante una tabla con cuatro columnas etiquetadas con 
número-préstamo, número-pago, fecha-pago e impor¬ 
te-pago, como se describe en la Figura 2.25. 

2.9.3. Representación tabular de los conjuntos 
de relaciones 

Sea R un conjunto de relaciones, sean a¡, a 2 ,.. .,a m el con¬ 
junto de atributos formados por la unión de las claves 
primarias de cada uno de los conjuntos de entidades que 
participan en R, y sean b h b 2 ,...,b n los atributos des¬ 
criptivos de R (si los hay). El conjunto de relaciones se 
representa mediante una tabla llamada R con una colum¬ 
na por cada uno de los atributos del conjunto: 

(«i, a 2 ,...,aj U { b { , b 2 ,...,b n } 

Como ilustración considérese el conjunto de rela¬ 
ciones prestatario del diagrama E-R de la Figura 2.8. 
Este conjunto de relaciones involucra los dos siguien¬ 
tes conjuntos de entidades: 

• cliente, con la clave primaria id-cliente. 

• préstamo, con la clave primaria número-préstamo. 


Debido a que el conjunto de relaciones no tiene atri¬ 
butos, la tabla prestatario tiene dos columnas etiqueta¬ 
das id-cliente y número-préstamo, como se muestra en 
la Figura 2.22. 

2.9.3.I. Redundancia de tablas 

Un conjunto de relaciones uniendo un conjunto de enti¬ 
dades débiles con el correspondiente conjunto de enti¬ 
dades fuertes es un caso especial. Como se hizo notar 
en el Apartado 2.6, estas relaciones son varios a uno y 
no tienen atributos descriptivos. Además, la clave pri¬ 
maria de un conjunto de entidades débiles incluye la cla¬ 
ve primaria del conjunto de entidades fuertes. En el dia¬ 
grama E-R de la Figura 2.16, el conjunto de entidades 
débiles pago depende del conjunto de entidades fuertes 
préstamo a través del conjunto de relaciones pago-prés¬ 
tamo. La clave primaria de pago es {número-préstamo, 
número-pago} y la clave primaria de préstamo es {núme¬ 
ro-préstamo}. Como pago-préstamo no tiene atributos 
descriptivos, la tabla para pago-préstamo tendría dos 
columnas, número-préstamo y número-pago. La tabla 
para el conjunto de entidades pago tiene cuatro colum¬ 
nas, número-préstamo, número-pago, fecha-pago e 
importe-pago. Cada combinación ( número-préstamo, 
número-pago ) en pago-préstamo también se encontra¬ 
ría en la tabla pago, y viceversa. Por tanto, la tabla pago- 
préstamo es redundante. En general, la tabla para el 
conjunto de relaciones que une un conjunto de entida¬ 
des débiles con su correspondiente conjunto de enti¬ 
dades fuertes es redundante y no necesita estar presen¬ 
te en una representación tabular de un diagrama E-R. 


número-préstamo 

número-pago 

fecha-pago 

importe-pago 

P-11 

53 

1 junio 2001 

125 

P-14 

69 

28 mayo 2001 

500 

P-15 

22 

23 mayo 2001 

300 

P-16 

58 

18 junio 2001 

135 

P-17 

5 

10 mayo 2001 

50 

P-17 

6 

7 junio 2001 

50 

P-17 

7 

17 junio 2001 

100 

P-23 

11 

17 mayo 2001 

75 

P-93 

103 

3 junio 2001 

900 

P-93 

104 

13 junio 2001 

200 


FIGURA 2.25. La tabla pago. 
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id-cliente 

número-préstamo 

01.928.374 

P-11 

01.928.374 

P-23 

24.466.880 

P-93 

32.112.312 

P-17 

33.557.799 

P-16 

55.555.555 

P-14 

67.789.901 

P-15 

96.396.396 

P-17 


FIGURA 2.26. La tabla prestatario. 

2.9.3.2. Combinación de tablas 

Considérese un conjunto AB de relaciones varios a uno 
del conjunto de entidades A al conjunto de entidades B. 
Usando el esquema de construcción de tablas descrito 
previamente se consiguen tres tablas: A, B y AS. Supón¬ 
gase además que la participación de A en la relación es 
total; es decir, cada entidad a en el conjunto de entida¬ 
des A debe participar en la relación AS. Entonces se 
pueden combinar las tablas A y AS para formar una úni¬ 
ca tabla consistente en la unión de las columnas de 
ambas tablas. 

Como ilustración considérese el diagrama E-R de la 
Figura 2.27. La doble línea del diagrama E-R indica que 
la participación de cuenta en cuenta-sucursal es total. 
Así, una cuenta no puede existir sin estar asociada con 
una sucursal particular. Además, el conjunto de rela¬ 
ciones cuenta-sucursal es varios a uno desde cuenta a 
sucursal. Por lo tanto, se puede combinar la tabla para 
cuenta-sucursal con la tabla para cuenta y se necesitan 
sólo las dos tablas siguientes: 

• cuenta, con los atributos número-cuenta, saldo y 
nombre-cuenta 

• sucursal, con los atributos nombre-sucursal, ciu¬ 
dad-sucursal y activo 

En el caso de relaciones uno a uno, la tabla del con¬ 
junto de relaciones se puede combinar con las tablas de 
cualquiera de los conjuntos de entidades. Las tablas se 
pueden combinar incluso si la participación es parcial 
usando valores nulos; en el ejemplo anterior se usarían 
valores nulos para el atributo nombre-sucursal para las 
cuentas que no tengan una sucursal asociada. 


2.9.4. Atributos compuestos 

Los atributos compuestos se manejan creando un atri¬ 
buto separado para cada uno de los atributos compo¬ 
nentes; no se crea una columna separada para el propio 
atributo compuesto. Supóngase que dirección es un atri¬ 
buto compuesto del conjunto de entidades cliente y que 
los componentes de dirección son ciudad y calle. La 
tabla generada de cliente contendría las columnas calle- 
dirección y ciudad-direccióm, no hay una columna sepa¬ 
rada para dirección. 

2.9.5. Atributos multivalorados 

Se ha visto que los atributos en un diagrama E-R gene¬ 
ralmente se asocian directamente en columnas para las 
tablas apropiadas. Los atributos multivalorados, sin 
embargo, son una excepción; para estos atributos se 
crean tablas nuevas. 

Para un atributo multivalorado M se crea una tabla 
T con una columna C que corresponde a la clave pri¬ 
maria del conjunto de entidades o conjunto de relacio¬ 
nes del que M es atributo. Como ilustración considére¬ 
se el diagrama E-R de la Figura 2.22. El diagrama 
incluye el atributo multivalorado nombre-subordinado. 
Para este atributo multivalorado se crea una tabla nom¬ 
bre-subordinado con columnas nombres, referencian- 
do al atributo nombre-subordinado de empleado, e id- 
empleado, representado la clave primaria del conjunto 
de entidades empleado. Cada subordinado de un em¬ 
pleado se representa como una única ñla en la tabla. 

2.9.6. Representación tabular 
de la generalización 

Hay dos métodos diferentes para transformar a forma 
tabular un diagrama E-R que incluya generalización. 
Aunque la generalización a la que se va a hacer refe¬ 
rencia es la de la Figura 2.17, para simplificar esta dis¬ 
cusión se incluye sólo la primera capa de los conjuntos 
de entidades de nivel más bajo —es decir, empleado y 
cliente. Se asume que nombre es la clave primaria de 
persona. 

1. Crear una tabla para el conjunto de entidades de 
nivel más alto. Para cada conjunto de entidades 



FIGURA 2.27. Diagrama E-R. 
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de nivel más bajo, crear una tabla que incluya una 
columna para cada uno de los atributos de ese 
conjunto de entidades más una columna por cada 
atributo de la clave primaria del conjunto de enti¬ 
dades de nivel más alto. Así, para el diagrama E- 
R de la Figura 2.15, se tienen tres tablas: 

• persona, con atributos nombre, calle y ciudad 

• empleado, con atributos nombre y salario 

• cliente, con atributos nombre, límite-crédito 

2. Es posible una representación alternativa si la 
generalización es disjunta y completa —es decir, 
si no hay ninguna entidad que sea miembro de 
dos conjuntos de entidades de menor nivel direc¬ 
tamente debajo de un conjunto de entidades de 
nivel más alto, y si cada entidad del conjunto de 
entidades de nivel más alto también pertenece a 
uno de los conjuntos de entidades de nivel más 
bajo. Aquí no se crea una tabla para el conjunto 
de entidades de nivel más alto. En su lugar, para 
cada conjunto de entidades de nivel más bajo 
se crea una tabla que incluya una columna por 
cada atributo del conjunto de entidades más 
una columna por cada atributo del conjunto de 
entidades de nivel más alto. Entonces, para el 
diagrama E-R de la Figura 2.15 se tienen dos 
tablas. 

• empleado, con atributos nombre, calle, ciudad 
y sueldo 


• cliente, con atributos nombre, calle, ciudad y 
límite-crédito 

Las relaciones cuenta-ahorro y cuenta-corrien¬ 
te correspondientes a esas tablas tienen número- 
cuenta como clave primaria. 

Si se usara el segundo método para una generaliza¬ 
ción solapada, algunos valores se almacenarían varias 
veces innecesariamente. Por ejemplo, si una persona es 
tanto empleado como cliente, los valores de calle y ciu¬ 
dad se almacenarían dos veces. Si la generalización no 
fuera completa (es decir, si alguna persona no fuera ni 
empleado no cliente) entonces se necesitaría una tabla 
extra persona para representarlos. 

2.9.7. Representación tabular 
de la agregación 

Transformar a forma tabular un diagrama E-R que inclu¬ 
ya agregación es sencillo. Considérese el diagrama de 
la Figura 2.19. La tabla para el conjunto de relaciones 
dirige entre la agregación de trabaja-en y el conjunto de 
entidades director incluye una columna para cada atri¬ 
buto de la clave primaria del conjunto de entidades direc¬ 
tor y del conjunto de relaciones trabaja-en. También 
incluiría una columna para los atributos descriptivos, si 
los hubiera, del conjunto de relaciones dirige. Por tan¬ 
to, se transforman los conjuntos de relaciones y los con¬ 
juntos de entidades dentro de la entidad agregada. 


2.10. EL LENGUAJE DE MODELADO UNIFICADO UML 

(Unilied Modeling Language)** 


Los diagramas entidad-relación ayudan a modelar el 
componente de representación de datos de un sistema 
software. La representación de datos, sin embargo, 
sólo forma parte de un diseño completo de un siste¬ 
ma. Otros componentes son modelos de interacción 
del usuario con el sistema, especificación de módu¬ 
los funcionales del sistema y su interacción, etc. El 
lenguaje de modelado unificado (UML, Unified 
Modeling Language) es un estándar propuesto para la 
creación de especificaciones de varios componentes 
de un sistema software. Algunas de las partes de UML 
son: 

• Diagrama de clase. Un diagrama de clase es simi¬ 
lar a un diagrama E-R. Más adelante en este apar¬ 
tado se mostrarán algunas características de los dia¬ 
gramas de clase y cómo se corresponden con los 
diagramas E-R. 

• Diagrama de caso de uso. Los diagramas de caso 
de uso muestran la interacción entre los usuarios 
y el sistema, en particular los pasos de las tareas 


que realiza el usuario (tales como prestar dinero o 
matricularse de una asignatura). 

• Diagrama de actividad. Los diagramas de acti¬ 
vidad describen el flujo de tareas entre varios com¬ 
ponentes de un sistema. 

• Diagrama de implementación. Los diagramas de 
implementación muestran los componentes del sis¬ 
tema y sus interconexiones tanto en el nivel del 
componente software como el hardware. 

Aquí no se intentará proporcionar un tratamiento 
detallado de las diferentes partes de UML. Véanse las 
notas bibliográficas para encontrar referencias de UML. 
En su lugar se ilustrarán algunas características de 
UML mediante ejemplos. 

La Figura 2.28 muestra varios constructores de dia¬ 
gramas E-R y sus constructores equivalentes de los 
diagramas de clase UML. Más abajo se describen estos 
constructores. UML muestra los conjuntos de entidades 
como cuadros y, a diferencia de E-R, muestra los atri¬ 
butos dentro del cuadro en lugar de como elipses sepa- 
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1. conjuntos de 

entidades y atributos 


2. relaciones 


3. restricciones 
de cardinalidad 


4. generalización 
y especialización 



diagrama E-R 

FIGURA 2.28. S ímbolos usados en la notación de diagramas de clase UML. 


diagrama de clase en UML 


radas. UML modela realmente objetos, mientras que 
E-R modela entidades. Los objetos son como entidades 
y tienen atributos, pero además proporcionan un con¬ 
junto de funciones (denominadas métodos) que se pue¬ 
den invocar para calcular valores en términos de los atri¬ 
butos de los objetos, o para modificar el propio objeto. 
Los diagramas de clase pueden describir métodos ade¬ 
más de atributos. Los objetos se tratan en el Capítulo 8. 

Los conjuntos de relaciones binarias se representan 
en UML dibujando simplemente una línea que conecte 
los conjuntos de entidades. Se escribe el nombre del 
conjunto de relaciones adyacente a la línea. También se 
puede especificar el papel que juega un conjunto de enti¬ 
dades en un conjunto de relaciones escribiendo el nom¬ 
bre del papel en un cuadro, junto con los atributos del 
conjunto de relaciones, y conectar el cuadro con una 
línea discontinua a la línea que describe el conjunto de 


relaciones. Este cuadro se puede tratar entonces como 
un conjunto de entidades, de la misma forma que una 
agregación en los diagramas E-R puede participar en 
relaciones con otros conjuntos de entidades. 

La relaciones no binarias no se pueden representar 
directamente en UML —se deben convertir en relacio¬ 
nes binarias por la técnica que se describió en el Apar¬ 
tado 2.4.3. 

Las restricciones de cardinalidad se especifican en 
UML de la misma forma que en los diagramas E-R, de 
la forma i.. s, donde i denota el mínimo y h el máximo 
número de relaciones en que puede participar una enti¬ 
dad. Sin embargo, se debería ser consciente que la ubi¬ 
cación de las restricciones es exactamente el inverso de 
la ubicación de las restricciones en los diagramas E-R, 
como muestra la Figura 2.28. La restricción 0..* en el 
lado E2 y 0..1 en el lado El significa que cada entidad 
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E2 puede participar a lo sumo en una relación, mientras 
que cada entidad El puede participar en varias relacio¬ 
nes; en otras palabras, la relación es varios a uno de E2 
a EX. 

Los valores como 1 o * se pueden escribir en los 
arcos; el valor 1 sobre un arco se trata equivalentemente 
como 1..1, mientras que * es equivalente a 0..*. 

La generalización y especialización se representan 
en el diagrama E-R conectando conjuntos de entida¬ 
des por una línea con un triángulo al final correspon¬ 
diente al conjunto de entidades más general. Por ejem¬ 


plo, el conjunto de entidades persona es una generali¬ 
zación de cliente y empleado. Los diagramas UML 
también pueden representar explícitamente las restric¬ 
ciones de generalizaciones disjuntas y solapadas. La 
Figura 2.28 muestra generalizaciones disjuntas y sola¬ 
padas de cliente y empleado a persona. Recuérdese 
que se la generalización de cliente / empleado a per¬ 
sona es disjunta, y significa que ninguna entidad pue¬ 
de ser a la vez un cliente y un empleado. Una genera¬ 
lización solapada permite que una persona sea tanto 
cliente como empleado. 


2.11. RESUMEN 


• El modelo de datos entidad-relación (E-R) se basa 
en una percepción del mundo real consistente en un 
conjunto de objetos básicos llamados entidades y en 
relaciones entre esos objetos. 

• El modelo está pensado principalmente para el pro¬ 
ceso de diseño de la base de datos. Fue desarrollado 
para facilitar el diseño permitiendo la especificación 
de un esquema de la empresa. Tal esquema repre¬ 
senta la estructura lógica general de la base de datos. 
Esta estructura general se puede expresar gráficamente 
mediante un diagrama E-R. 

• Una entidad es un objeto que existe y es distinguible 
de otros objetos. Se expresa la distinción asociando 
con cada entidad un conjunto de atributos que des¬ 
criben el objeto. 

• Una relación es una asociación entre diferentes en¬ 
tidades. Un conjunto de relaciones es una colec¬ 
ción de relaciones del mismo tipo y un conjunto de 
entidades es una colección de entidades del mismo 
tipo. 

• La correspondencia de cardinalidades expresa el 
número de entidades a las que otra entidad se puede 
asociar a través de un conjunto de relaciones. 

• Una superclave de un conjunto de entidades es un 
conjunto de uno o más atributos que, tomados colec¬ 
tivamente, permiten identificar unívocamente una enti¬ 
dad en un conjunto de entidades. Se elige una super¬ 
clave mínima para cada conjunto de entidades de entre 
sus superclaves; la superclave mínima se denomina 
la clave primaria del conjunto de entidades. Análo¬ 
gamente, un conjunto de relaciones es un conjunto de 
uno o más atributos que, tomados colectivamente, per¬ 
miten identificar unívocamente una relación en un 
conjunto de relaciones. De igual forma se elige una 
superclave mínima para cada conjunto de relaciones 
de entre todas sus superclaves; ésta es la clave pri¬ 
maria del conjunto de relaciones. 

• Un conjunto de entidades que no tiene suficientes atri¬ 
butos para formar una clave primaria se denomina 

conjunto de entidades débiles. Un conjunto de enti¬ 


dades que tiene una clave primaria se denomina con¬ 
junto de entidades fuertes. 

• La especialización y la generalización definen una re¬ 
lación de contenido entre un conjunto de entidades de 
nivel más alto y uno o más conjuntos de entidades 
de nivel más bajo. La especialización es el resultado de 
tomar un subconjunto de un conjunto de entidades 
de nivel más alto para formar un conjunto de entida¬ 
des de nivel más bajo. La generalización es el resul¬ 
tado de tomar la unión de dos o más conjuntos dis¬ 
juntos de entidades (de nivel más bajo) para producir 
un conjunto de entidades de nivel más alto. Los atri¬ 
butos de los conjuntos de entidades de nivel más alto 
los heredan los conjuntos de entidades de nivel más 
bajo. 

• La agregación es una abstracción en la que los con¬ 
juntos de relaciones (junto con sus conjuntos de enti¬ 
dades asociados) se tratan como conjuntos de entida¬ 
des de nivel más alto, y pueden participar en las 
relaciones. 

• Las diferentes características del modelo E-R ofrecen 
al diseñador de bases de datos numerosas decisiones 
de cómo representar mejor la empresa que se mode¬ 
la. Los conceptos y objetos pueden, en ciertos casos, 
representarse mediante entidades, relaciones o atri¬ 
butos. Ciertos aspectos de la estructura global de la 
empresa se pueden describir mejor usando conjuntos 
de entidades débiles, generalización, especialización 
o agregación. A menudo el diseñador debe sopesar las 
ventajas de un modelo simple y compacto frente a 
otros más precisos pero más completos. 

• Una base de datos que se representa en un diagrama 
E-R se puede representar mediante una colección de 
tablas. Para cada conjunto de entidades y para cada 
conjunto de relaciones de la base de datos hay una 
única tabla a la que se le asigna el nombre del con¬ 
junto de entidades o del conjunto de relaciones corres¬ 
pondiente. Cada tabla tiene un número de columnas, 
cada una de las cuales tiene un nombre único. La con¬ 
versión de una representación de base de datos en un 
diagrama E-R a un formato de tabla se basa en la deri- 
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vación de un diseño de bases de datos relacional des¬ 
de un diagrama E-R. 

El lenguaje de modelado unificado (UML) propor¬ 
ciona un medio gráfico de modelar varios compo¬ 


nentes de un sistema software. El componente dia¬ 
grama de clase de UML se basa en diagramas E-R. 
Sin embargo, hay algunas diferencias entre ambos que 
se deben tener presentes. 


TÉRMINOS DE REPASO 


• Agregación 

• Atributo derivado 

• Atributos 

• Atributos descriptivos 

• Atributos monovalorados y multivalorados 

• Atributos simples y compuestos 

• Conjunto de entidades 

• Conjunto de relaciones 

• Conjunto de relaciones binario 

• Conjunto de relaciones recursivo 

• Conjuntos de entidades débiles y fuertes 
— Atributos discriminantes 

— Relaciones identificadoras 

• Correspondencia de cardinalidad: 

— Relación uno a uno 

— Relación uno a varios 
— Relación varios a uno 
— Relación varios a varios 

• Diagrama E-R 

• Dominio 


Entidad 

Especialización y generalización 

— Superclase y subclase 

— Herencia de atributos 

— Herencia simple y múltiple 

— Pertenencia definida por condición y definida por 
el usuario 

— Generalización disjunta y solapada 
Grado de un conjunto de relaciones 
Lenguaje de modelado unificado (UML) 

Modelo de datos entidad-relación 
Papel 

Participación 

— Participación total 

— Participación parcial 
Relación 

Restricción de completitud 

— Generalización total y parcial 
Superclave, clave candidata y clave primaria 
Valor nulo 


EJERCICIOS 


2.1. Expliqúense las diferencias entre los términos clave pri¬ 
maria, clave candidata y superclave. 

2.2. Construyase un diagrama E-R para una compañía de 
seguros de coches cuyos clientes poseen uno o más 
coches. Cada coche tiene asociado un número de cero a 
cualquier valor que almacena el número de accidentes. 

2.3. Constrúyase un diagrama E-R para un hospital con un 
conjunto de pacientes y un conjunto de médicos. Aso¬ 
cíese con cada paciente un registro de las diferentes prue¬ 
bas y exámenes realizados. 

2.4. Una oficina de registro de una universidad mantiene 
datos acerca de las siguientes entidades: (a) asignaturas, 
incluyendo el número, título, programa, y prerrequisi- 
tos; (b) ofertas de asignaturas, incluyendo número de 
asignatura, año, semestre, número de sección, profe¬ 
sores), horarios y aulas; (c) estudiantes, incluyendo id- 
estudiante, nombre y programa; y (d) profesores, inclu¬ 
yendo número de identificación, nombre, departamento 
y título. Además, la matrícula de los estudiantes en asig¬ 
naturas y las notas concedidas a estudiantes en cada asig¬ 


natura en la que están matriculados se deben modelar 
adecuadamente. 

Constrúyase un diagrama E-R para la oficina de 
registro. Documéntense todas las decisiones que se 
hagan acerca de restricciones de correspondencia. 

2.5. Considérese una base de datos usada para registrar las 
notas que obtienen los estudiantes en diferentes exáme¬ 
nes de diferentes ofertas de asignaturas. 

a. Constrúyase un diagrama E-R que modele exáme¬ 
nes como entidades y use una relación ternaria para 
esta base de datos. 

b. Constrúyase un diagrama E-R alternativo que use 
sólo una relación binaria entre estudiantes y ofertas- 
asignaturas. Asegúrese de que sólo existe una rela¬ 
ción entre un par determinado estudiante y oferta- 
asignatura y de que aún se pueden representar las 
notas que obtiene un estudiante en diferentes exá¬ 
menes de una oferta de una asignatura. 

2.6. Constrúyanse tablas apropiadas para cada uno de los dia¬ 
gramas E-R de los Ejercicios 2.2 al 2.4. 
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2.7. Diséñese un diagrama E-R para almacenar los logros 
de su equipo deportivo favorito. Se deberían almace¬ 
nar los partidos jugados, los resultados de cada parti¬ 
do, los jugadores de cada partido y las estadísticas indi¬ 
viduales de cada jugador para cada partido. Las 
estadísticas de resumen se deberían modelar como atri¬ 
butos derivados. 

2.8. Extiéndase el diagrama E-R del ejercicio anterior para 
almacenar la misma información para todos los equi¬ 
pos de una liga. 

2.9. Expliqúense las diferencias entre conjunto de entida¬ 
des débiles y fuertes. 

2.10. Se puede convertir cualquier conjunto de entidades 
débiles en un conjunto de entidades fuertes simple¬ 
mente añadiendo los atributos apropiados. ¿Por qué, 
entonces, se tienen conjuntos de entidades débiles? 

2.11. Defínase el concepto de agregación. Propónganse ejem¬ 
plos para los que este concepto es útil. 

2.12. Considérese el diagrama de la Figura 2.29, que mode¬ 
la una librería en línea. 

a. Lístense los conjuntos de entidades y sus claves pri¬ 
marias. 

b. Supóngase que la librería añade casetes de música 
y discos compactos a su colección. El mismo ele¬ 
mento musical puede estar presente en formato de 
casete o de disco compacto con diferentes precios. 
Extiéndase el diagrama E-R para modelar esta adi¬ 


ción, ignorando el efecto sobre las cestas de la com¬ 
pra. 

c. Extiéndase ahora el diagrama E-R usando generali¬ 
zación para modelar el caso en que una cesta de la 
compra pueda contener cualquier combinación de 
libros, casetes de música o discos compactos. 

2.13. Considérese un diagrama E-R en el que el mismo con¬ 
junto de entidades aparece varias veces. ¿Por qué está 
permitida esta redundancia, una mala práctica que se 
debería evitar siempre que sea posible? 

2.14. Considérese una base de datos de una universidad para 
la planificación de las aulas para los exámenes finales. 
Esta base de datos se modelaría mediante un único con¬ 
junto de entidades examen, con atributos nombre-asig¬ 
natura, número-sección, número-aula y hora. Alter¬ 
nativamente se podrían definir uno o más conjuntos de 
entidades, con conjuntos de relaciones para sustituir 
algunos de los atributos del conjunto de entidades exa¬ 
men, como 

• asignatura con atributos nombre, departamento y 
número-a 

• sección con atributos número-s y matriculados, que 
es un conjunto de entidades débiles dependiente de 
curso. 

• aula con atributos número-a, capacidad y edificio. 

a. Muéstrese en un diagrama E-R el uso de los tres 
conjuntos de entidades adicionales listados. 



FIGURA 2.29. Diagrama E-R para el Ejercicio 2.12. 
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b. Expliqúense las características que influirían en la 
decisión de incluir o no incluir cada uno de los con¬ 
juntos de entidades adicionales. 

2.15. Cuando se diseña un diagrama E-R para un desarrollo 
particular se tienen varias alternativas entre las que hay 
que decidir. 

a. ¿Qué criterio se deberá considerar para hacer la elec¬ 
ción apropiada? 

b. Diséñense tres alternativas de diagrama E-R para 
representar la oficina de registro de la universidad 
del Ejercicio 2.4. Lístense las ventajas de cada uno. 
Decídase por una de las alternativas. 

2.16. Un diagrama E-R se puede ver como un grafo. ¿Qué 
significan los siguientes términos de estructura en un 
esquema de desarrollo? 

a. El grafo es inconexo. 

b. El grafo es acíclico. 

2.17. En el Apartado 2.4.3 se representó una relación terna¬ 
ria (Figura 2.30a) usando relaciones binarias, como se 
muestra en la Figura 2.30b. Considérese la alternativa 
mostrada en la Figura 2.30c. Discútanse las ventajas 
relativas a estas dos representaciones alternativas entre 
una relación ternaria y relaciones binarias. 

2.18. Considérese la representación de una relación ternaria 
usando relaciones binarias como se describió en el 
Apartado 2.4.3 (mostrado en la figura 2.30b). 

a. Muéstrese un ejemplar simple de E, A, B, C, R A , R,¡ 
y R c que no puedan corresponder a ningún ejemplar 
de A, B, C y R. 

b. Modifiqúese el diagrama E-R de la Figura 2.30b 
para introducir restricciones que garanticen que cual¬ 
quier ejemplar E, A, B, C, R A , R B y R c que satisfa¬ 
ga las restricciones corresponda a un ejemplar de A, 
B, C y R. 


c. Modifiqúese la traducción de arriba para manejar 
restricciones de participación total sobre las rela¬ 
ciones ternarias. 

d. La representación de arriba requiere que se cree un 
atributo clave primaria para E. Muéstrese cómo tra¬ 
tar E como un conjunto de entidades débiles de for¬ 
ma que no se requiera un atributo clave primaria. 

2.19. Un conjunto de entidades débiles siempre se puede con¬ 
vertir en un conjunto de entidades fuertes añadiéndole 
a sus atributos los atributos clave primaria de su con¬ 
junto de entidades identificadoras. Descríbase qué tipo 
de redundancia resultaría si se hiciese así. 

2.20. Diséñese una jerarquía de especialización-generaliza- 
ción para las ventas de una compañía de vehículos a 
motor. La compañía vende motocicletas, coches de 
pasajeros, furgonetas y autobuses. Justifiqúese la colo¬ 
cación de los atributos en cada nivel de la jerarquía. 
Expliqúese por qué se deberían colocar en un nivel más 
alto o más bajo. 

2.21. Expliqúese la distinción entre las restricciones de dise¬ 
ño definidas por condición y las definidas por el usua¬ 
rio. ¿Cuáles de estas restricciones se pueden compro¬ 
bar automáticamente? Expliqúese la respuesta. 

2.22. Expliqúese la distinción entre las restricciones disjun¬ 
tas y solapadas. 

2.23. Expliqúese la distinción entre las restricciones totales 
y parciales. 

2.24. En la Figura 2.31 se muestra una estructura reticular 
de generalización y especialización. Para los conjun¬ 
tos de entidades A, B y C expliqúese cómo se heredan 
los atributos desde los conjuntos de entidades de nivel 
más alto X e Y. Discútase cómo manejar el caso en que 
un atributo de X tiene el mismo nombre que un atribu¬ 
to de Y. 




(c) 

FIGURA 2.30. Diagrama E-R para el Ejercicio 2.17 (no se muestran los atributos). 
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FIGURA 2.31. Diagrama E-R para el Ejercicio 2.18 (no se muestran los atributos). 


2.25. Dibújense equivalentes UML de los diagramas E-R de 
las Figuras 2.9c, 2.10, 2.12, 2.13 y 2.17. 

2.26. Considérense dos bancos separados que deciden fusio¬ 
narse. Asúmase que ambos bancos usan exactamente 
el mismo esquema de bases de datos E-R, el de la Figu¬ 
ra 2.22. (Obviamente, esta suposición es muy irreal; se 
considera un caso más realista en el Apartado 19.8.) Si 
la fusión del banco tiene una única base de datos, hay 
varios problemas potenciales: 

• La posibilidad de que los dos bancos originales ten¬ 
gan sucursales con el mismo nombre. 

• La posibilidad de que algunos clientes sean clientes 
de ambos bancos originales. 

• La posibilidad de que algunos números de préstamo 
o de cuenta fueran usados en ambos bancos origina¬ 
les (para diferentes préstamos o cuentas, por supues¬ 
to). 


Para cada uno de estos problemas potenciales des¬ 
críbase por qué existen de hecho dificultades poten¬ 
ciales. Propóngase una solución a este problema. Expli¬ 
qúese cualquier cambio que se tendría que hacer para 
la solución y descríbase cómo afecta al esquema y a 
los datos. 

2.27. Reconsidérese la situación descrita en el Ejercicio 2.26 
bajo la suposición de que un banco está en España y el 
otro en Portugal. Por lo tanto, los bancos usan el esque¬ 
ma de la Figura 2.22, excepto que el banco portugués 
usa un número de identificación asignado por el gobier¬ 
no portugués, mientras que el banco español usa el 
D.N.I. español para la identificación de clientes. ¿Qué 
problemas (además de los identificados en el Ejercicio 
2.24) ocurrirían en este caso multinacional? ¿Cómo se 
podrían resolver? Asegúrese de considerar ambos 
esquemas y los valores de los datos actuales en la cons¬ 
trucción de la respuesta. 


NOTAS BIBLIOGRÁFICAS 


El modelo de datos E-R fue introducido por Chen [1976]. 
Teorey et al. [1986] usó una metodología de diseño lógi¬ 
co para bases de datos relaciónales que usa el modelo 
E-R extendido. La correspondencia entre los modelos 
E-R extendido y relacional se discutió por Lyngbaek y 
Vianu [1987], y por Marlowitz y Shoshani [1992]. Se 
han propuesto varios lenguajes de manipulación de datos 
para el modelo E-R: GERM (Benneworth et al. [1981]), 
GORDAS (Elmasri y Wiederhold [1981]) y ERROL 
(Markowitz y Raz [1983]). Un lenguaje de consulta grá¬ 
fico para las bases de datos E-R se propuso por Zhang y 
Mendelzon [1983], y por ElMasri y Larson [1985]. 


Los conceptos de generalización, especialización 
y agregación se introdujeron por Smith y Smith 
[1977], y se extendieron en Hammer y McLeod 
[1981]. Lenzerini y Santucci [1983] han usado estos 
conceptos para definir las restricciones del modelo 
E-R. 

Thalheim [2000] proporciona un tratamiento deta¬ 
llado de libros de texto de la investigación en el mode¬ 
lado E-R. En Batini et al. [1992] y Elmasri y Navathe 
[2000] se ofrecen discusiones sobre libros de texto bási¬ 
cos. Davis et al. [1983] proporciona una colección de 
artículos del modelo E-R. 


HERRAMIENTAS 


Muchos sistemas de bases de datos proporcionan 
herramientas para el diseño de bases de datos que 
soportan diagramas E-R. Estas herramientas ayudan 
al diseñador a crear diagramas E-R y pueden crear 
automáticamente las tablas correspondientes en una 
base de datos. Véanse las notas bibliográficas del 
Capítulo 1 para consultar referencias a sitios Web de 


fabricantes de bases de datos. Hay también algunas 
herramientas de modelado de datos independientes 
que soportan diagramas E-R y diagramas de clase 
UML. Entre ellas están Rational Rose (www.ratio- 
nal.com/products/rose). Visio Enterprise (véase 
www.visio.com) y ERwin (búsquese ERwin en el sitio 
www.cai.com/products). 
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CAPÍTULO 



EL MODELO RELACIONAL 


E l modelo relacional se ha establecido actualmente como el principal modelo de datos 
para las aplicaciones de procesamiento de datos. Ha conseguido la posición principal 
debido a su simplicidad, que facilita el trabajo del programador en comparación con 
otros modelos anteriores como el de red y el jerárquico. 

En este capítulo se estudia en primer lugar los fundamentos del modelo relacional, que pro¬ 
porciona una forma muy simple y potente de representar datos. A continuación se describen 
tres lenguajes formales de consulta; los lenguajes de consulta se usan para especificar las soli¬ 
citudes de información. Los tres que se estudian en este capítulo no son cómodos de usar, pero 
a cambio sirven como base formal para lenguajes de consulta que sí lo son y que se estudiarán 
más adelante. El primer lenguaje de consulta, el álgebra relacional, se estudia en detalle. El 
álgebra relacional forma la base del lenguaje de consulta SQL ampliamente usado. A conti¬ 
nuación se proporcionan visiones generales de otros dos lenguajes formales: el cálculo rela¬ 
cional de tupias y el cálculo relacional de dominios, que son lenguajes declarativos de consulta 
basados en la lógica matemática. El cálculo relacional de dominios es la base del lenguaje QBE. 

Existe una amplia base teórica de las bases de datos relaciónales. En este capítulo se estu¬ 
dia la base teórica referida a las consultas. En el Capítulo 7 se examinarán aspectos de la teo¬ 
ría de bases de datos relaciónales que ayudan en el diseño de esquemas de bases de datos 
relaciónales, mientras que en los Capítulos 13 y 14 se estudian aspectos de la teoría que se refie¬ 
ren al procesamiento eficiente de consultas. 


3.1. LA ESTRUCTURA DE LAS BASES DE DATOS RELACIONALES 


Una base de datos relacional consiste en un conjunto de 
tablas, a cada una de las cuales se le asigna un nombre 
exclusivo. Cada tabla tiene una estructura parecida a la 
presentada en el Capítulo 2, donde se representaron las 
bases de datos E-R mediante tablas. Cada fila de la tabla 
representa una relación entre un conjunto de valores. 
Dado que cada tabla es un conjunto de dichas relacio¬ 
nes, hay una fuerte correspondencia entre el concepto 
de tabla y el concepto matemático de relación , del que 
toma su nombre el modelo de datos relacional. A con¬ 
tinuación se introduce el concepto de relación. 

En este capítulo se utilizarán varias relaciones dife¬ 
rentes para ilustrar los conceptos subyacentes al modelo 
de datos relacional. Estas relaciones representan parte 
de una entidad bancaria. Se diferencian ligeramente de 
las tablas que se utilizaron en el Capítulo 2, por lo que 
se puede simplificar la representación. En el Capítulo 7 
se estudiarán los criterios sobre la adecuación de las 
estructuras relaciónales. 

3.1.1. Estructura básica 

Considérese la tabla cuenta de la Figura 3.1. Tiene tres 
cabeceras de columna: número-cuenta, nombre-sucur¬ 
sal y saldo. Siguiendo la terminología del modelo rela¬ 


cional se puede hacer referencia a estas cabeceras como 
atributos (igual que se hizo en el modelo E-R en el 
Capítulo 2). Para cada atributo hay un conjunto de valo¬ 
res permitidos, llamado dominio de ese atributo. Para 
el atributo nombre-sucursal, por ejemplo, el dominio es 
el conjunto de los nombres de las sucursales. Suponga¬ 
mos que D ] denota el conjunto de todos los números de 
cuenta, D 2 el conjunto de todos los nombres de sucur¬ 
sal y D 3 el conjunto de los saldos. Como se vio en el 
Capítulo 2 todas las filas de cuenta deben consistir en 
una tupia (vj, v 2 , v 3 ), donde v¡ es un número de cuenta 
(es decir, v : está en el dominio D { ), v 2 es un nombre de 
sucursal (es decir, v 2 está en el dominio D 2 ) y v 3 es un 
saldo (es decir, v 3 está en el dominio Z) 3 ). En general, 


número-cuenta 

nombre-sucursal 

saldo 

C-101 

Centro 

500 

C-102 

Navacerrada 

400 

C-201 

Galapagar 

900 

C-215 

Becerril 

700 

C-217 

Galapagar 

750 

C-222 

Moralzarzal 

700 

C-305 

Collado Mediano 

350 


FIGURA 3.1. La relación cuenta. 
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cuenta sólo contendrá un subconjunto del conjunto de 
todas las filas posibles. Por tanto, cuenta es un subcon¬ 
junto de 

D j x D 2 x 

En general, una tabla de n atributos debe ser un sub¬ 
conjunto de 

D x x D 2 x ... x D n _ l x D n 

Los matemáticos definen las relaciones como sub¬ 
conjuntos del producto cartesiano de la lista de domi¬ 
nios. Esta definición se corresponde de manera casi 
exacta con la definición de tabla dada anteriormente. La 
única diferencia es que aquí se han asignado nombres 
a los atributos, mientras que los matemáticos sólo uti¬ 
lizan «nombres» numéricos, utilizando el entero 1 para 
denotar el atributo cuyo dominio aparece en primer lugar 
en la lista de dominios, 2 para el atributo cuyo dominio 
aparece en segundo lugar, etcétera. Como las tablas son 
esencialmente relaciones, se utilizarán los términos 
matemáticos relación y tupia en lugar de los términos 
tabla y fila. Una variable tupia es una variable que 
representa a una tupia; en otras palabras, una tupia que 
representa al conjunto de todas las tupias. 

En la relación cuenta de la Figura 3.1 hay siete tupias. 
Supóngase que la variable tupia t hace referencia a la 
primera tupia de la relación. Se utiliza la notación 
t\número-cuenta ] para denotar el valor de t en el atributo 
número-cuenta. Por tanto, t[número-cuenta] = «C-101» 
y t[nombre-sucursal ] = «Centro». De manera alterna¬ 
tiva, se puede escribir í[l] para denotar el valor de la 
tupia t en el primer atributo ( número-cuenta ), f[2] para 
denotar nombre-sucursal, etcétera. Dado que las rela¬ 
ciones son conjuntos se utiliza la notación matemática t 
E r para denotar que la tupia t está en la relación r. 

El orden en que aparecen las tupias es irrelevante, 
dado que una relación es un conjunto de tupias. Así, si 
las tupias de una relación se muestran ordenadas como 
en la Figura 3.1, o desordenadas, como en la Figura 3.2, 
no importa; las relaciones de estas figuras son las mis¬ 
mas, ya que ambas contienen el mismo conjunto de 
tupias. 

Se exigirá que, para todas las relaciones r, los domi¬ 
nios de todos los atributos de r sean atómicos. Un domi¬ 
nio es atómico si los elementos del dominio se 


número-cuenta 

nombre-sucursal 

saldo 

C-101 

Centro 

500 

C-215 

Becerril 

700 

C-102 

Navacerrada 

400 

C-305 

Collado Mediano 

350 

C-201 

Galapagar 

900 

C-222 

Moralzarzal 

700 

C-217 

Galapagar 

750 


FIGURA 3.2. La relación cuenta con las tupias desordenadas. 


consideran unidades indivisibles. Por ejemplo, el con¬ 
junto de los enteros es un dominio atómico, pero el con¬ 
junto de todos los conjuntos de enteros es un dominio 
no atómico. La diferencia es que no se suele considerar 
que los enteros tengan subpartes, pero sí se considera 
que los conjuntos de enteros las tienen; por ejemplo, los 
enteros que forman cada conjunto. Lo importante no es 
lo que sea el propio dominio, sino la manera en que se 
utilizan los elementos del dominio en la base de datos. 
El dominio de todos los enteros sería no atómico si se 
considerase que cada entero fuera una lista ordenada de 
cifras. En todos los ejemplos se supondrá que los domi¬ 
nios son atómicos. En el Capítulo 9 se estudiarán exten¬ 
siones al modelo de datos relacional para permitir 
dominios no atómicos. 

Es posible que varios atributos tengan el mismo 
dominio. Por ejemplo, supóngase que se tiene una rela¬ 
ción cliente que tiene los tres atributos nombre-cliente, 
calle-cliente y ciudad-cliente y una relación empleado 
que incluye el atributo nombre-empleado. Es posible 
que los atributos nombre-cliente y nombre-empleado 
tengan el mismo dominio, el conjunto de todos los nom¬ 
bres de personas, que en el nivel físico son cadenas de 
caracteres. Los dominios de saldo y nombre-sucursal, 
por otra parte, deberían ser distintos. Quizás es menos 
claro si nombre-cliente y nombre-sucursal deberían tener 
el mismo dominio. En el nivel físico, tanto los nombres 
de clientes como los nombres de sucursales son cade¬ 
nas de caracteres. Sin embargo, en el nivel lógico puede 
que se desee que nombre-cliente y nombre-sucursal ten¬ 
gan dominios diferentes. 

Un valor de dominio que es miembro de todos los 
dominios posibles es el valor nulo, que indica que el 
valor es desconocido o no existe. Por ejemplo, supón¬ 
gase que se incluye el atributo número-teléfono en la rela¬ 
ción cliente. Puede ocurrir que un cliente no tenga número 
de teléfono, o que su número de teléfono no figure en la 
guía. Entonces habrá que recurrir a los valores nulos para 
indicar que el valor es desconocido o que no existe. Más 
adelante se verá que los valores nulos crean algunas difi¬ 
cultades cuando se tiene acceso a la base de datos o 
cuando se actualiza y que, por tanto, deben eliminarse si 
es posible. Se asumirá inicialmente que no hay valores 
nulos y en el Apartado 3.3.4 se describirá el efecto de los 
valores nulos en las diferentes operaciones. 

3.1.2. Esquema de la base de datos 

Cuando se habla de bases de datos se debe diferenciar 
entre el esquema de la base de datos, o diseño lógico 
de la misma, y el ejemplar de la base de datos, que es 
una instantánea de los datos de la misma en un momento 
dado. 

El concepto de relación se corresponde con el con¬ 
cepto de variable de los lenguajes de programación. El 
concepto de esquema de la relación se corresponde 
con el concepto de definición de tipos de los lenguajes 
de programación. 
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Resulta conveniente dar un nombre a los esquemas 
de las relaciones, igual que se dan nombres a las defi¬ 
niciones de tipos en los lenguajes de programación. Se 
adopta el convenio de utilizar nombres en minúsculas 
para las relaciones y nombres que comiencen por una 
letra mayúscula para los esquemas de las relaciones. 
Siguiendo esta notación se utilizará Esquema-cuenta 
para denotar el esquema de la relación de la relación 
cuenta. Por tanto, 

Esquema-cuenta = ( número-cuenta, 
nombre-sucursal, saldo) 

Se denota el hecho de que cuenta es una relación de 
Esquema-cuenta mediante 

cuenta ( Esquema-cuenta) 

En general, los esquemas de las relaciones incluyen 
una lista de los atributos y de sus dominios correspon¬ 
dientes. La definición exacta del dominio de cada atri¬ 
buto no será relevante hasta que se discuta el lenguaje 
SQL en el Capítulo 4. 

El concepto de ejemplar de relación se corresponde 
con el concepto de valor de una variable en los lengua¬ 
jes de programación. El valor de una variable dada puede 
cambiar con el tiempo; de manera parecida, el conte¬ 
nido del ejemplar de una relación puede cambiar con el 
tiempo cuando la relación se actualiza. Sin embargo, se 
suele decir simplemente «relación» cuando realmente 
se quiere decir «ejemplar de la relación». 

Como ejemplo de ejemplar de una relación, consi¬ 
dérese la relación sucursal de la Figura 3.3. El esquema 
de esa relación es 

Esquema-relación = ( nombre-sucursal, 
ciudad-sucursal, activos) 

Obsérvese que el atributo nombre de la sucursal apa¬ 
rece tanto en Esquema-sucursal como en Esquema- 
cuenta. Esta duplicidad no es una coincidencia. Más 
bien, utilizar atributos comunes en los esquemas de las 
relaciones es una manera de relacionar las tupias de rela¬ 
ciones diferentes. Por ejemplo, supóngase que se desea 
obtener información sobre todas las cuentas abiertas en 
sucursales ubicadas en Arganzuela. Primero se busca 


nombre de la sucursal 

ciudad de la sucursal 

activos 

Galapagar 

Arganzuela 

7.500 

Centro 

Arganzuela 

9.000.000 

Becerril 

Aluche 

2.000 

Segovia 

Cerceda 

3.700.000 

Navacerrada 

Aluche 

1.700.000 

Navas de la Asunción 

Alcalá de Henares 

1.500 

Moralzarzal 

La Granja 

2.500 

Collado Mediano 

Aluche 

8.000.000 


FIGURA 3.3. La relación sucursal. 


en la relación sucursal para encontrar los nombres de 
todas las sucursales sitas en Arganzuela. Luego, para 
cada una de ellas, se mira en la relación cuenta para 
encontrar la información sobre las cuentas abiertas en 
esa sucursal. Esto no es sorprendente: recuérdese que 
los atributos que forma la clave primaria de un conjunto 
de entidades fuertes aparecen en la tabla creada para 
representar el conjunto de entidades, así como en las 
tablas creadas para crear relaciones en las que partici¬ 
par el conjunto de entidades. 

Continuemos con el ejemplo bancario. Se necesita 
una relación que describa la información sobre los clien¬ 
tes. El esquema de la relación es: 

Esquema-cliente = ( nombre-cliente, 
calle-cliente, ciudad-cliente) 

En la Figura 3.4 se muestra un ejemplo de la relación 
cliente ( Esquema-cliente). Obsérvese que se ha omi¬ 
tido el atributo id-cliente , que se usó en el Capítulo 2, 
porque no se desea tener esquemas de relación más 
pequeños en este ejemplo. Se asume que el nombre de 
cliente identifica unívocamente un cliente; obviamente, 
esto no es cierto en el mundo real, pero las suposicio¬ 
nes hechas en estos ejemplos los hacen más sencillos 
de entender. 

En una base de datos del mundo real, id-cliente (que 
podría ser el número de la seguridad social o un identi- 
ficador generado por el banco) serviría para identificar 
unívocamente a los clientes. 

También se necesita una relación que describa la aso¬ 
ciación entre los clientes y las cuentas. El esquema de 
la relación que describe esta asociación es: 

Esquema-impositor = ( nombre-cliente, 
número-cuenta) 

En la Figura 3.5 se muestra un ejemplo de la relación 
impositor ( Esquema-impositor). 

Puede parecer que, para el presente ejemplo banca- 
rio, se podría tener sólo un esquema de relación, en vez 
de tener varios. Es decir, puede resultar más sencillo 
para el usuario pensar en términos de un esquema de 


nombre-cliente 

calle-cliente 

ciudad-cliente 

Abril 

Preciados 

Valsaín 

Amo 

Embajadores 

Arganzuela 

Badorrey 

Delicias 

Valsaín 

Fernández 

Jazmín 

León 

Gómez 

Carretas 

Cerceda 

González 

Arenal 

La Granja 

López 

Mayor 

Peguerinos 

Pérez 

Carretas 

Cerceda 

Rodríguez 

Yeserías 

Cádiz 

Rupérez 

Ramblas 

León 

Santos 

Mayor 

Peguerinos 

Valdivieso 

Goya 

Vigo 


FIGURA 3.4. La relación cliente. 


55 












FUNDAMENTOS DE BASES DE DATOS 


nombre cliente 

número cuenta 


número-préstamo 

nombre-sucursal 

importe 

Abril 

C-102 


P-11 

Collado Mediano 

900 

Gómez 

C-101 


P-14 

Centro 

1.500 

González 

C-201 


P-15 

Navacerrada 

1.500 

González 

C-217 


P-16 

Navacerrada 

1.300 

López 

C-222 


P-17 

Centro 

1.000 

Rupérez 

C-215 


P-23 

Moralzarzal 

2.000 

Santos 

C-305 


P-93 

Becerril 

500 


FIGURA 3.5. La relación impositor. FIGURA 3.6. La relación préstamo. 


relación, en lugar de en términos de varios esquemas. 
Supóngase que sólo se utilizara una relación para el 
ejemplo, con el esquema 

(, nombre-sucursal, ciudacl-sucursal, activos, 
nombre-cliente, calle-cliente, ciudad-cliente, 
número-cuenta, saldo) 

Obsérvese que si un cliente tiene varias cuentas hay 
que repetir su dirección una vez por cada cuenta. Es 
decir, hay que repetir varias veces parte de la informa¬ 
ción. Esta repetición supone un gasto inútil y se evita 
mediante el uso de varias relaciones, como en el ejem¬ 
plo presente. 

Además, si una sucursal no tiene ninguna cuenta (por 
ejemplo, una sucursal recién creada que todavía no tiene 
clientes), no se puede construir una tupia completa en la 
relación única anterior, dado que no hay todavía ningún 
dato disponible referente a cliente ni a cuenta. Para repre¬ 
sentar las tupias incompletas hay que utilizar valores nulos 
que indiquen que ese valor es desconocido o no existe. 
Por tanto, en el ejemplo presente, los valores de nombre- 
cliente, calle-cliente, etcétera, deben quedar nulos. Uti¬ 
lizando varias relaciones se puede representar la 
información de las sucursales de un banco sin clientes 
sin utilizar valores nulos. Sencillamente, se utiliza una 
tupia en Esquema-sucursal para representar la informa¬ 
ción de la sucursal y sólo crear tupias en los otros esque¬ 
mas cuando esté disponible la información adecuada. 

En el Capítulo 7 se estudiarán los criterios para deci¬ 
dir cuándo un conjunto de esquemas de relaciones es 
más apropiado que otro en términos de repetición de la 
información y de la existencia de valores nulos. Por 
ahora se supondrá que los esquemas de las relaciones 
vienen dados de antemano. 

Se incluyen dos relaciones más para describir los 
datos de los préstamos concedidos en las diferentes 
sucursales del banco: 

Esquema-préstamo = ( número-préstamo, 
nombre-sucursal, importe ) 
Esquema-prestatario = ( nombre-cliente, 
número-préstamo ) 

Las relaciones de ejemplo préstamo ( Esquema-prés¬ 
tamo) y prestatario ( Esquema-prestatario ) se muestran 
en las Figuras 3.5 y 3.6, respectivamente. 


La entidad bancaria que se ha descrito se deriva del 
diagrama E-R mostrado en la Figura 3.8. Los esquemas 
de las relaciones se corresponden con el conjunto de 
tablas que se podrían generar utilizando el método esbo¬ 
zado en el Apartado 2.9. Obsérvese que las tablas para 
cuenta-sucursal y préstamo-sucursal se han combinado 
en las tablas de cuenta y préstamo respectivamente. Esta 
combinación es posible dado que las relaciones son de 
varios a uno desde cuenta y préstamo, respectivamente, 
a sucursal y, además, la participación de cuenta y prés¬ 
tamo en las relaciones correspondientes es total, como 
indican las líneas dobles en la figura. Finalmente, obsér¬ 
vese que la relación cliente puede contener información 
sobre clientes que ni tengan cuenta ni un préstamo en 
el banco. 

La entidad bancaria aquí descrita servirá como ejem¬ 
plo principal en este capítulo y en los siguientes. Cuando 
sea necesario, habrá que introducir más esquemas de 
relaciones para ilustrar casos concretos. 

3.1.3. Claves 

Los conceptos de superclave, de clave candidato y de 
clave primaria, tal y como se discute en el Capítulo 2, 
también son aplicables en el modelo relacional. Por 
ejemplo, en Esquema-sucursal, tanto {nombre-sucur¬ 
sal} como {nombre-sucursal, ciudad-sucursal} son 
superclaves. {nombre-sucursal, ciudad-sucursal} no es 
una clave candidata porque {nombre-sucursal} es un 
subconjunto de {nombre-sucursal, ciudad-sucursal} y 
{nombre-sucursal} es una superclave. Sin embargo, 
{nombre-sucursal} es una clave candidata, y servirá 
también como clave primaria para estos fines. El atri¬ 
buto ciudad-sucursal no es una superclave, dado que 
dos sucursales de la misma ciudad pueden tener nom¬ 
bres diferentes (y diferentes volúmenes de activos). 


nombre cliente 

número préstamo 

Fernández 

P-16 

Gómez 

P-93 

Gómez 

P-15 

López 

P-14 

Pérez 

P-17 

Santos 

P-11 

Sotoca 

P-23 

Valdivieso 

P-17 


FIGURA 3.7. La relación prestatario. 
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FIGURA 3.8. Diagrama E-R de la entidad bancaria. 


Sea R el esquema de una relación. Si se dice que un 
subconjunto K de R es una superclave de R para las rela¬ 
ciones r(R) en las que no hay dos tupias diferentes que 
tengan los mismos valores en todos los atributos de K. 
Es decir, si ?j y t 2 están en R y /j ^ t 2 , entonces t l [A] £ 
t 2 [K\. 

Si el esquema de una base de datos relacional se basa 
en las tablas derivadas de un esquema E-R es posible 
determinar la clave primaria del esquema de una rela¬ 
ción a partir de las claves primarias de los conjuntos de 
entidades o de relaciones de los que se deriva el esquema: 

• Conjunto de entidades fuertes. La clave prima¬ 
ria del conjunto de entidades se convierte en la 
clave primaria de la relación. 

• Conjunto de entidades débiles. La tabla y, por 
tanto, la relación correspondientes a un conjunto 
de entidades débiles incluyen 

— Los atributos del conjunto de entidades débi¬ 
les. 

— La clave primaria del conjunto de entidades fuer¬ 
tes del que depende el conjunto de entidades 
débiles. 

La clave primaria de la relación consiste en la 
unión de la clave primaria del conjunto de enti¬ 
dades fuertes y el discriminante del conjunto de 
entidades débil. 

• Conjunto de relaciones. La unión de las claves 
primarias de los conjuntos de entidades relacio¬ 
nados se transforma en una superclave de la rela¬ 


ción. Si la relación es de varios a varios, esta su¬ 
perclave es también la clave primaria. En el Apar¬ 
tado 2.4.2 se describe la manera de determinar las 
claves primarias en otros casos. Recuérdese del 
Apartado 2.9.3 que no se genera ninguna tabla para 
los conjuntos de relaciones que vinculan un con¬ 
junto de entidades débiles con el conjunto de enti¬ 
dades fuertes correspondiente. 

• Tablas combinadas. Recuérdese del Apartado 
2.9.3 que un conjunto binario de relaciones de 
varios a uno entre A y B puede representarse 
mediante una tabla que consista en los atributos de 
A y en los atributos (si hay alguno) del conjunto 
de relaciones. La clave primaria de la entidad 
«varios» se transforma en la clave primaria de la 
relación (es decir, si el conjunto de relaciones es 
de varios a uno entre A y B, la clave primaria de A 
es la clave primaria de la relación). Para los con¬ 
juntos de relaciones de uno a uno la relación se 
construye igual que en el conjunto de relaciones 
de varios a uno. Sin embargo, cualquiera de las 
claves primarias del conjunto de entidades puede 
elegirse como clave primaria de la relación, dado 
que ambas son claves candidatas. 

• Atributos multivalorados. Recuérdese del Apar¬ 
tado 2.9.4 que un atributo multivalorado M se 
representa mediante una tabla consistente en la 
clave primaria del conjunto de entidades o de rela¬ 
ciones del que M es atributo y en una columna C 
que guarda un valor concreto de M. La clave pri¬ 
maria del conjunto de entidades o de relaciones 
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junto con el atributo C se convierte en la clave 
primaria de la relación. 

A partir de la lista precedente se puede ver que el 
esquema de una relación puede incluir entre sus atribu¬ 
tos la clave primaria de otro esquema, digamos r 2 . Este 
atributo es una clave externa de r ] que hace referencia 
a r 2 . La relación r, también se denomina la relación 
referenciante de la dependencia de clave externa, y r 2 
se denomina la relación referenciada de la clave 
externa. Por ejemplo, el atributo nombre-sucursal de 
Esquema-cuenta es una clave externa de Esquema- 
cuenta referenciando a Esquema-sucursal, ya que nom¬ 
bre-sucursal es la clave primaria de Esquema-sucursal. 
En cualquier ejemplar de la base de datos, dada una 
tupia t a de la relación cuenta, debe haber alguna tupia 
t b en la relación cuenta tal que el valor del atributo nom¬ 
bre-sucursal de t a sea el mismo que el valor de la clave 
primaria, nombre-sucursal, de t b . 

Es obligado listar los atributos que forman clave pri¬ 
maria de un esquema de relación antes que el resto; por 
ejemplo, el atributo nombre-sucursal de Esquema-sucur¬ 
sal se lista en primer lugar, ya que es la clave primaria. 

3.1.4. Diagramas de esquema 

Un esquema de bases de datos, junto con las dependen¬ 
cias de clave primaria y externa, se puede mostrar grá¬ 
ficamente mediante diagramas de esquema. La Figura 
3.9 muestra el diagrama de esquema del ejemplo ban- 
cario. Cada relación aparece como un cuadro con los 
atributos listados dentro de él y el nombre de la relación 
sobre él. Si hay atributos clave primaria, una línea hori¬ 
zontal cruza el cuadro con los atributos clave primaria 
listados sobre ella. Las dependencias de clave exter¬ 
na aparecen como flechas desde los atributos clave 
externa de la relación referenciante a la clave primaria 
de la relación referenciada. 

No hay que confundir un diagrama de esquema con 
un diagrama E-R. En particular, los diagramas E-R no 
muestran explícitamente los atributos clave externa, 
mientras que los diagramas de esquema sí. 


Muchos sistemas de bases de datos proporcionan 
herramientas de diseño con una interfaz gráfica de usua¬ 
rio para la creación de diagramas de esquema. 

3.1.5. Lenguajes de consulta 

Un lenguaje de consulta es un lenguaje en el que un 
usuario solicita información de la base de datos. Estos 
lenguajes suelen ser de un nivel superior que el de los 
lenguajes de programación habituales. Los lenguajes de 
consulta pueden clasificarse como procedimentales o 
no procedimentales. En los lenguajes procedimenta¬ 
les el usuario instruye al sistema para que lleve a cabo 
una serie de operaciones en la base de datos para calcu¬ 
lar el resultado deseado. En los lenguajes no procedi¬ 
mentales el usuario describe la información deseada 
sin dar un procedimiento concreto para obtener esa infor¬ 
mación. 

La mayor parte de los sistemas comerciales de bases 
de datos relaciónales ofrecen un lenguaje de consulta 
que incluye elementos de los enfoques procedimental 
y no procedimental. Se estudiarán varios lenguajes 
comerciales en el Capítulo 4. El Capítulo 5 trata los 
lenguajes QBE y Datalog, este último parecido a Pro¬ 
log. 

En este capítulo se examinarán los lenguajes «puros»: 
el álgebra relacional es procedimental, mientras que el 
cálculo relacional de tupias y el de dominios son no pro¬ 
cedimentales. Estos lenguajes de consulta son rígidos y 
formales, y carecen del «azúcar sintáctico» de los len¬ 
guajes comerciales, pero ilustran las técnicas funda¬ 
mentales para la extracción de datos de las bases de 
datos. 

Aunque inicialmente sólo se estudiarán las consul¬ 
tas, un lenguaje de manipulación de datos completo no 
sólo incluye un lenguaje de consulta, sino también un 
lenguaje para la modificación de las bases de datos. 
Estos lenguajes incluyen órdenes para insertar y borrar 
tupias, así como órdenes para modificar partes de las 
tupias existentes. Las modificaciones de las bases de 
datos se examinarán después de completar la discusión 
sobre las consultas. 


sucursal cuenta impositor cliente 



FIGURA 3.9. Diagrama de esquema para el banco. 
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3.2. EL ÁLGEBRA RELACIONAL 


El álgebra relacional es un lenguaje de consulta proce- 
dimental. Consta de un conjunto de operaciones que 
toman como entrada una o dos relaciones y producen 
como resultado una nueva relación. Las operaciones 
fundamentales del álgebra relacional son selección, pro¬ 
yección, unión, diferencia de conjuntos, producto car¬ 
tesiano y renombramiento. Además de las operaciones 
fundamentales hay otras operaciones, por ejemplo, inter¬ 
sección de conjuntos, reunión natural, división y asig¬ 
nación. Estas operaciones se definirán en términos de 
las operaciones fundamentales. 


3.2.1. Operaciones fundamentales 

Las operaciones selección, proyección y renombra¬ 
miento se denominan operaciones uñarías porque ope¬ 
ran sobre una sola relación. Las otras tres operaciones 
operan sobre pares de relaciones y se denominan, por 
lo tanto, operaciones binarias. 


3.2.1.1. La operación selección 

La operación selección selecciona tupias que satisfacen 
un predicado dado. Se utiliza la letra griega sigma 
minúscula (o) para denotar la selección. El predicado 
aparece como subíndice de o. La relación del argumento 
se da entre paréntesis a continuación de o. Por tanto, 
para seleccionar las tupias de la relación préstamo en 
que la sucursal es «Navacerrada» hay que escribir 


o. 


nombre-sucursal = «Navacerrada» 


{préstamo) 


Si la relación préstamo es como se muestra en la Ligura 
3.6, la relación que resulta de la consulta anterior es 
como se muestra en la Ligura 3.10. 

Se pueden buscar todas las tupias en las que el 
importe prestado sea mayor que 1.200 € escribiendo 


El predicado de selección puede incluir compara¬ 
ciones entre dos atributos. Para ilustrarlo, considérese 
la relación responsable-préstamo, que consta de tres 
atributos: nombre-cliente, nombre-banquero y número- 
préstamo, que especifica que un empleado concreto es 
el responsable del préstamo concedido a un cliente. Para 
hallar todos los clientes que se llaman igual que su res¬ 
ponsable de préstamos se puede escribir 

®nombre-cliente = nombre-banquero (responsable-préstamo) 

Dado que el valor especial nulo indica «valor des¬ 
conocido o inexistente», cualquier comparación que 
implique a un valor nulo se evalúa como falsa. 


3.2.I.2. La operación proyección 

Supóngase que se desea hacer una lista de todos los 
números de préstamo y del importe de los mismos, pero 
sin que aparezcan los nombres de las sucursales. La ope¬ 
ración proyección permite producir esta relación. La 
operación proyección es una operación unaria que 
devuelve su relación de argumentos, excluyendo algu¬ 
nos argumentos. Dado que las relaciones son conjun¬ 
tos, se eliminan todas las filas duplicadas. La proyección 
se denota por la letra griega mayúscula pi (El). Se crea 
una lista de los atributos que se desea que aparezcan en 
el resultado como subíndice de II. La relación de argu¬ 
mentos se escribe a continuación entre paréntesis. Por 
tanto, la consulta para crear una lista de todos los núme¬ 
ros de préstamo y del importe de los mismos puede 
escribirse como 


n 


número-préstamo, importe 


{préstamo) 


La relación que resulta de esta consulta se muestra en 
la Ligura 3.11. 


^importo 1200 {préstamo) 

En general, se permiten las comparaciones que uti¬ 
lizan =, *, <, <, > o > en el predicado de selección. Ade¬ 
más, se pueden combinar varios predicados en uno 
mayor utilizando las conectivas y (a) y o (v). Por tanto, 
para encontrar las tupias correspondientes a préstamos 
de más de 1.200 € concedidos por la sucursal de Nava- 
cerrada, se escribe 


Cnombre -sucursal = «Navacerrada» a importo 1200 


{préstamo) 


número-préstamo 

nombre-sucursal 

importe 

P-15 

P-16 

Navacerrada 

Navacerrada 

1.500 

1.300 


3.2.I.3. Composición de operaciones 
relaciónales 

Es importante el hecho de que el resultado de una ope¬ 
ración relacional sea también una relación. Considérese 
la consulta más compleja «Encontrar los clientes que 
viven en Peguerinos». Hay que escribir: 


número-préstamo 

importe 

P-11 

900 

P-14 

1.500 

P-15 

1.500 

P-16 

1.300 

P-17 

1.000 

P-23 

2.000 

P-93 

500 


FIGURA 3.11. Números de préstamo y sus importes. 


FIGURA 3.10. Resultado de cr nombre , sucursal = „ Navacerrada » (prés¬ 
tamo). 
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D nombre-cliente (*7 ciudad-cliente = «Peguerinos» (clientí ?)) 

Téngase en cuenta que, en vez de dar en el argumento 
de la operación proyección el nombre de una relación, 
se da una expresión que se evalúa como una relación. 

En general, dado que el resultado de una operación 
del álgebra relacional es del mismo tipo (relación) que 
los datos de entrada, las operaciones del álgebra rela¬ 
cional pueden componerse para formar una expresión 
del álgebra relacional. La composición de operacio¬ 
nes del álgebra relacional para formar expresiones del 
álgebra relacional es igual que la composición de ope¬ 
raciones aritméticas (como +, -, * y +) para formar 
expresiones aritméticas. La definición formal de las 
expresiones de álgebra relacional se estudia en el Apar¬ 
tado 3.2.2. 

3.2.1.4. La operación unión 

Considérese una consulta para averiguar el nombre de 
todos los clientes del banco que tienen una cuenta, un 
préstamo o ambas cosas. Obsérvese que la relación 
cliente no contiene esa información, dado que los clien¬ 
tes no necesitan tener ni cuenta ni préstamo en el banco. 
Para contestar a esta consulta hace falta la información 
de la relación impositor (Ligura 3.5) y la de la relación 
prestatario (Ligura 3.7). Se conoce la manera de averi¬ 
guar los nombres de todos los clientes con préstamos 
en el banco: 

U nombre-cliente ( prestatario ) 

También se conoce la manera de averiguar el nombre 
de los clientes con cuenta en el banco: 

^nombre-cliente (impOSÍtOi ) 

Para contestar a la consulta hace falta la unión de estos 
dos conjuntos; es decir, hacen falta todos los nombres 
de clientes que aparecen en alguna de las dos relacio¬ 
nes o en ambas. Estos datos se pueden averiguar 
mediante la operación binaria unión, denotada, como 
en la teoría de conjuntos, por U. Por tanto, la expresión 
buscada es 

U nombre-cliente ( prestatario) U n nombre _ cUente ( ÍmpOSÍtOr) 

La relación resultante de esta consulta aparece en la 
Ligura 3.10. Téngase en cuenta que en el resultado hay 
diez tupias, aunque hay siete prestatarios y seis impo- 
sitores distintos. Esta discrepancia aparente se debe a 
que Gómez, Santos y López son a la vez prestatarios e 
impositores. Dado que las relaciones son conjuntos, se 
eliminan los valores duplicados. 

Obsérvese que en este ejemplo se toma la unión de 
dos conjuntos, ambos consistentes en valores de nom¬ 
bre-cliente. En general, se debe asegurar que las unio¬ 
nes se realicen entre relaciones compatibles. Por 
ejemplo, no tendría sentido realizar la unión de las rela- 


nombre-cliente 

Abril 

Fernández 

Gómez 

González 

López 

Pérez 

Rupérez 

Santos 

Sotoca 

Valdivieso 

FIGURA 3.12. Nombres de todos los clientes que tienen 
un préstamo o una cuenta. 


dones préstamo y prestatario. La primera es una rela¬ 
ción con tres atributos, la segunda sólo tiene dos. Más 
aún, considérese la unión de un conjunto de nombres 
de clientes y de un conjunto de ciudades. Una unión así 
no tendría sentido en la mayor parte de los casos. Por 
tanto, para que una operación unión rU s sea válida hay 
que exigir que se cumplan dos condiciones: 

1. Las relaciones r y s deben ser de la misma aridad. 
Es decir, deben tener el mismo número de atributos. 

2. Los dominios de los atributos í-ésimos de r y de 5 
deben ser iguales para todo i. 

Téngase en cuenta que r y s pueden ser, en general, 
relaciones temporales que sean resultado de expresio¬ 
nes del álgebra relacional. 

3.2.I.5. La operación diferencia de conjuntos 

La operación diferencia de conjuntos, denotada por -, 
permite buscar las tupias que estén en una relación pero 
no en la otra. La expresión r - s da como resultado una 
relación que contiene las tupias que están en r pero no 
en 5 . 

Se pueden buscar todos los clientes del banco que 
tienen abierta una cuenta pero no tienen concedido nin¬ 
gún préstamo escribiendo 

n nombre-cliente (' mpositor) - Ti nombre . cliente ( prestatario ) 

La relación resultante de esta consulta aparece en la 
Ligura 3.13. 

Como en el caso de la operación unión, hay que ase¬ 
gurarse de que las diferencias de conjuntos se realicen 
entre relaciones compatibles. Por tanto, para que una 


nombre-cliente 

Abril 

González 

Rupérez 

FIGURA 3.13. Clientes con cuenta abierta pero sin prés¬ 
tamo concedido. 
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operación diferencia de conjuntos r — s sea válida hay 
que exigir que las relaciones ry s sean de la misma ari- 
dad y que los dominios de los atributos z-ésimos de r y 
s sean iguales. 

3.2.I.6. La operación producto cartesiano 

La operación producto cartesiano, denotada por un 
aspa (x), permite combinar información de cualesquiera 
dos relaciones. El producto cartesiano de las relaciones 
r, y r 2 como r x x r 2 . 

Recuérdese que las relaciones se definen como sub¬ 
conjuntos del producto cartesiano de un conjunto de 
dominios. A partir de esta definición ya se debe tener 
una intuición sobre la definición de la operación pro¬ 
ducto cartesiano. Sin embargo, dado que el mismo nom¬ 
bre de atributo puede aparecer tanto en r, como en r 2 , 
hay que crear un esquema de denominaciones para dis¬ 
tinguir entre ambos atributos. En este caso se logra 
adjuntando al atributo el nombre de la relación de la que 
proviene originalmente. Por ejemplo, el esquema de 
relación de r = prestatario x préstamo es 

{prestatario.nombre-cliente, prestatario.número- 
préstamo, préstamo.nombre-sucursal, prés¬ 
tamo.número-préstamo, préstamo.importe) 

Con este esquema se puede distinguir entre prestata¬ 
rio.número-préstamo y préstamo.número-préstamo. 
Para los atributos que sólo aparecen en uno de los dos 
esquemas se suele omitir el prefijo con el nombre de la 
relación. Esta simplificación no genera ambigüedad 
alguna. Por tanto, se puede escribir el esquema de rela¬ 
ción de r como 

( nombre-cliente, prestatario.número-préstamo, 
nombre-sucursal, préstamo.número-préstamo, 
importe) 

El acuerdo de denominaciones precedente exige que las 
relaciones que sean argumentos de la operación pro¬ 
ducto cartesiano tengan nombres diferentes. Esta exi¬ 
gencia causa problemas en algunos casos, como cuando 
se desea calcular el producto cartesiano de una relación 
consigo misma. Se produce un problema similar si se 
utiliza el resultado de una expresión del álgebra rela- 
cional en un producto cartesiano, dado que hará falta 
un nombre para la relación para poder hacer referencia 
a sus atributos. En el Apartado 3.2.1.7 se verá la manera 
de evitar estos problemas utilizando una operación 
renombramiento. 

Ahora que se conoce el esquema de relación de r = 
prestatario x préstamo hay que averiguar las tupias que 
aparecerán en r. Como se podía imaginar, se crea una 
tupia de r a partir de cada par de tupias posible: una de 
la relación prestatario y otra de la relación préstamo. 
Por tanto, r es una relación de gran tamaño, como se 
puede ver en la Figura 3.14, donde sólo se ha incluido 
una parte de las tupias que forman parte de r. 


Supóngase que se tienen n l tupias en prestatario y n 2 
tupias en préstamo. Por tanto, hay n¡ * n 2 maneras de esco¬ 
ger un par de tupias, una tupia de cada relación; por lo 
que hay n x * n 2 tupias en r. En concreto, obsérvese que 
para algunas tupias t de r puede ocurrir que t\prestata- 
rio.número-préstamo] & t[préstamo.número-préstamo]. 

En general, si se tienen las relaciones r x (R¡) y r 2 (R 2 ), 
r, x r 2 es una relación cuyo esquema es la concatena¬ 
ción de R, y de R 2 . La relación R contiene todas las 
tupias t para las que hay unas tupias í, en r t y t 2 en r 2 
para las que í[/?J = Zj[RJ y í[R 2 ] = LÍ^l- 

Supóngase que se desea averiguar los nombres de 
todos los clientes que tienen concedido un préstamo en 
la sucursal de Navacerrada. Se necesita para ello infor¬ 
mación de las relaciones préstamo y prestatario. Si se 
escribe 

^nombre-sucursal = «Navacerrada» (prestatario X préstamo) 

entonces el resultado es la relación mostrada en la Figura 
3.15. Se tiene una relación que sólo atañe a la sucursal 
de Navacerrada. Sin embargo, la columna nombre- 
cliente puede contener clientes que no tengan conce¬ 
dido ningún préstamo en la sucursal de Navacerrada. 
(Si no se ve el motivo por el que esto es cierto, recuér¬ 
dese que el producto cartesiano toma todos los empa¬ 
rejamientos posibles de una tupia de prestatario con una 
tupia de préstamo.) 

Dado que la operación producto cartesiano asocia 
todas las tupias de préstamo con todas las tupias de pres¬ 
tatario , se sabe que, si un cliente tiene concedido un 
préstamo en la sucursal de Navacerrada, hay alguna 
tupia de prestatario x préstamo que contiene su nom¬ 
bre y que prestatario.número-préstamo = préstamo.nú¬ 
mero-préstamo. Por tanto, si escribimos 

^ prestatario.número-préstamo = préstamo.número-préstamo 
Onombre-sucursal = «Navacerrada» (prestatario X 

préstamo)) 

sólo se obtienen las tupias de prestatario x préstamo 
que corresponden a los clientes que tienen concedido 
un préstamo en la sucursal de Navacerrada. 

Finalmente, dado que sólo se desea obtener nombre- 
cliente, se realiza una proyección: 

^ nombre-cliente (^prestatario,número-préstamo = préstamo.número-préstamo 
nombre-sucursal = «Navacerrada» {prestatario X 

préstamo))) 

El resultado de esta expresión se muestra en la Figura 
3.16 y es la respuesta correcta a la consulta formulada. 

3.2.I.7. La operación renombramiento 

A diferencia de las relaciones de la base de datos, los 
resultados de las expresiones de álgebra relacional no 
tienen un nombre que se pueda utilizar para referirse a 
ellas. Resulta útil poder ponerles nombre; el operador 
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nombre-cliente 

prestatario.número-préstamo 

préstamo.número-préstamo 

nombre-sucursal 

importe 

Santos 

P-17 

P-11 

Collado Mediano 

900 

Santos 

P-17 

P-14 

Centro 

1.500 

Santos 

P-17 

P-15 

Navacerrada 

1.500 

Santos 

P-17 

P-16 

Navacerrada 

1.300 

Santos 

P-17 

P-17 

Centro 

1.000 

Santos 

P-17 

P-23 

Moralzarzal 

2.000 

Santos 

P-17 

P-93 

Becerril 

500 

Gómez 

P-23 

P-11 

Collado Mediano 

900 

Gómez 

P-23 

P-14 

Centro 

1.500 

Gómez 

P-23 

P-15 

Navacerrada 

1.500 

Gómez 

P-23 

P-16 

Navacerrada 

1.300 

Gómez 

P-23 

P-17 

Centro 

1.000 

Gómez 

P-23 

P-23 

Moralzarzal 

2.000 

Gómez 

P-23 

P-93 

Becerril 

500 

López 

P-15 

P-11 

Collado Mediano 

900 

López 

P-15 

P-14 

Centro 

1.500 

López 

P-15 

P-15 

Navacerrada 

1.500 

López 

P-15 

P-16 

Navacerrada 

1.300 

López 

P-15 

P-17 

Centro 

1.000 

López 

P-15 

P-23 

Moralzarzal 

2.000 

López 

P-15 

P-93 

Becerril 

500 

Valdivieso 

P-17 

P-11 

Collado Mediano 

900 

Valdivieso 

P-17 

P-14 

Centro 

1.500 

Valdivieso 

P-17 

P-15 

Navacerrada 

1.500 

Valdivieso 

P-17 

P-16 

Navacerrada 

1.300 

Valdivieso 

P-17 

P-17 

Centro 

1.000 

Valdivieso 

P-17 

P-23 

Moralzarzal 

2.000 

Valdivieso 

P-17 

P-93 

Becerril 

500 

Fernández 

P-16 

P-11 

Collado Mediano 

900 

Fernández 

P-16 

P-14 

Centro 

1.500 

Fernández 

P-16 

P-15 

Navacerrada 

1.500 

Fernández 

P-16 

P-16 

Navacerrada 

1.300 

Fernández 

P-16 

P-17 

Centro 

1.000 

Fernández 

P-16 

P-23 

Moralzarzal 

2.000 

Fernández 

P-16 

P-93 

Becerril 

500 


FIGURA 3.14. Resultado de prestatario x préstamo. 


nombre-cliente 

prestatario.número-préstamo 

préstamo.número-préstamo 

nombre-sucursal 

importe 

Santos 

P-17 

P-15 

Navacerrada 

1.500 

Santos 

P-17 

P-16 

Navacerrada 

1.300 

Gómez 

P-23 

P-15 

Navacerrada 

1.500 

Gómez 

P-23 

P-16 

Navacerrada 

1.300 

López 

P-15 

P-15 

Navacerrada 

1.500 

López 

P-15 

P-16 

Navacerrada 

1.300 

Sotoca 

P-14 

P-15 

Navacerrada 

1.500 

Sotoca 

P-14 

P-16 

Navacerrada 

1.300 

Pérez 

P-93 

P-15 

Navacerrada 

1.500 

Pérez 

P-93 

P-16 

Navacerrada 

1.300 

Gómez 

P-11 

P-15 

Navacerrada 

1.500 

Gómez 

P-11 

P-16 

Navacerrada 

1.300 

Valdivieso 

P-17 

P-15 

Navacerrada 

1.500 

Valdivieso 

P-17 

P-16 

Navacerrada 

1.300 

Fernández 

P-16 

P-15 

Navacerrada 

1.500 

Fernández 

P-16 

P-16 

Navacerrada 

1.300 


FIGURA 3.15. Resultado de CT norribre . sucljrsal = „ Navacerrada „ (prestatario x préstamo). 
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nombre-cliente 

Férnandez 

López 


FIGURA 3.16. Resultado den 


préstamo = préstamo.número-préstamo nombre-sucursal = «Navacerrada» 


nombre-cliente ( ®prestatario.número- 


(.prestatario x préstamo))). 


renombramiento, denotado por la letra griega rho 
minúscula (p), permite realizar esta tarea. Dada una 
expresión E del álgebra relacional, la expresión 

Px(E) 

devuelve el resultado de la expresión E con el nombre x. 

Las relaciones r por sí mismas se consideran expre¬ 
siones (triviales) del álgebra relacional. Por tanto, tam¬ 
bién se puede aplicar la operación renombramiento a 
una relación r para obtener la misma relación con un 
nombre nuevo. 

Otra forma de la operación renombramiento es la 
siguiente. Supóngase que una expresión del álgebra rela¬ 
cional E tiene aridad n. Por tanto, la expresión 

Px(A h A 2 , ...A n ) (E) 

devuelve el resultado de la expresión E con el nombre 
x y con los atributos con el nombre cambiado aA„ A 2 , 

Para ilustrar el uso del renombramiento de las rela¬ 
ciones, considérese la consulta «Buscar el máximo saldo 
de cuenta del banco». La estrategia empleada para obte¬ 
ner el resultado es 1) calcular una relación intermedia 
consistente en los saldos que no son el máximo y 2) rea¬ 
lizar la diferencia entre la relación IT sa¡do ( cuenta) y la 
relación intermedia recién calculada. 

Paso 1: Para calcular la relación intermedia hay que 
comparar los valores de los saldos de todas las cuentas. 
Esta comparación se puede hacer calculando el producto 
cartesiano cuenta x cuenta y formando una selección 
para comparar el valor de cualesquiera dos saldos que 
aparezcan en una tupia. En primer lugar hay que crear 
un mecanismo para distinguir entre los dos atributos 
saldo. Se utilizará la operación renombramiento para 
cambiar el nombre de una referencia a la relación cuenta; 
así, se puede hacer referencia dos veces a la relación sin 
ambigüedad alguna. 

La relación temporal que se compone de los saldos 
que no son el máximo puede escribirse ahora como 

I ^ cítenla.saldo r úenla.saldo < ¡¡.saldo ( CUetlta X f) ( ¡ ( cUCÍlt(¡))) 

Esta expresión proporciona los saldos de la rela¬ 
ción cuenta para los que aparece un saldo mayor 
en alguna parte de la relación cuenta (cuyo nombre se 
ha cambiado a d). El resultado contiene todos los sal¬ 
dos salvo el máximo. Esta relación se muestra en la 
Figura 3.17. 


saldo 

500 

400 

700 

750 

350 


FIGURA 3.17. Resultado de la subexpresión n cuanta . saWo 

(rr cuenta-saldo < d.saldo (CUeíltd X f) d [cuenta))) , 


Paso 2: La consulta para averiguar el máximo saldo 
de cuenta del banco puede escribirse de la manera 
siguiente: 


^ (saldo ( cuenta) n C uenta.saldo 

(cuenta x p d (cuenta))) 


(^cuenta.saldo < d.saldo 


En la Figura 3.18 se muestra el resultado de esta con¬ 
sulta. 

Considérese la siguiente consulta como un nuevo 
ejemplo de la operación renombramiento: «Averiguar 
los nombres de todos los clientes que viven en la misma 
calle y en la misma ciudad que Gómez». Se puede obte¬ 
ner la calle y la ciudad en la que vive Gómez escribiendo 


n 




calle-cliente, ciudad-cliente V '-'nombre-cliente = «Gómez. 


(cliente)) 


Sin embargo, para hallar a otros clientes que vivan 
en esa calle y en esa ciudad hay que hacer referencia 
por segunda vez a la relación cliente. En la consulta 
siguiente se utiliza la operación renombramiento sobre 
la expresión anterior para darle al resultado el nombre 
dirección-Gómez y para cambiar el nombre de los atri¬ 
butos a calle y ciudad en lugar de calle-cliente y ciu¬ 
dad-cliente'. 


^-cliente .nombre-cliente (®cliente .calle-cliente = dirección-Gómez a 
cliente.ciudad-cliente = dirección-Gómez. ciudad (cliente x 


Pdirección-Gómez Icalle, ciudad) \ . calle-cliente , ciudad-cliente 

nombre-cliente = «Gómez» (diente))))) 


El resultado de esta consulta, cuando se aplica a la rela¬ 
ción cliente de la Figura 3.4, se muestra en la Figura 
3.19. 

La operación renombramiento no es estrictamente 
necesaria, dado que es posible utilizar una notación posi- 
cional para los atributos. Se pueden nombrar los atri¬ 
butos de una relación de manera implícita utilizando 
una notación posicional, donde $1, $2, ... hagan refe- 


| saldo | 

900 

FIGURA 3.18. Saldo máximo de las cuentas del 
banco. 
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nombre-cliente 

Gómez 

Pérez 


FIGURA 3.19. Los clientes que viven en la misma calle 
y en la misma ciudad que Gómez. 

rencia al primer atributo, al segundo, etcétera. La nota¬ 
ción posicional también se aplica a los resultados de las 
operaciones del álgebra relacional. La siguiente expre¬ 
sión del álgebra relacional ilustra el uso de la notación 
posicional con el operador unario cr. 

°$ 2=$3 (R* R) 

Si una operación binaria necesita distinguir entre las dos 
relaciones que son sus operandos, se puede utilizar una 
notación posicional parecida para los nombres de las 
relaciones. Por ejemplo, $R 1 puede hacer referencia al 
primer operando y $R2, al segundo. Sin embargo, la 
notación posicional no resulta conveniente para las per¬ 
sonas, dado que la posición del atributo es un número 
en vez de un nombre de atributo fácil de recordar. Por 
tanto, en este libro no se utiliza la notación posicional. 

3.2.2. Definición formal del álgebra relacional 

Las operaciones que se vieron en el Apartado 3.2.1 per¬ 
miten dar una definición completa de las expresiones 
del álgebra relacional. Las expresiones fundamentales 
del álgebra relacional se componen de alguna de las 
siguientes: 

• Una relación de la base de datos 

• Una relación constante 

Una relación constante se escribe listando sus tupias 
entre llaves ({}), por ejemplo {(C-101,Centro,500) (C- 
215, Becerril, 700)}. 

Las expresiones generales del álgebra relacional se 
construyen a partir de subexpresiones menores. Sean £j 
y E 2 expresiones de álgebra relacional. Todas las siguien¬ 
tes son expresiones del álgebra relacional: 

• e { ue 2 

• E x -E 2 

• E { xE 2 

• o P (E : ), donde P es un predicado de atributos de £j 

• ILj (£j), donde S es una lista que se compone de 
algunos de los atributos de £j 

• p v (£j), donde x es el nuevo nombre del resultado 
de £j. 


3.2.3. Otras operaciones 

Las operaciones fundamentales del álgebra relacio¬ 
nal son suficientes para expresar cualquier consulta del 
álgebra relacional 1 . Sin embargo, si uno se limita úni¬ 
camente a las operaciones fundamentales, algunas con¬ 
sultas habituales resultan de expresión intrincada. Por 
tanto, se definen otras operaciones que no añaden poten¬ 
cia al álgebra, pero que simplifican las consultas habi¬ 
tuales. Para cada operación nueva se facilita una 
expresión equivalente utilizando sólo las operaciones 
fundamentales. 

3.2.3.1. La operación intersección de conjuntos 

La primera operación adicional del álgebra relacional 
que se definirá es la intersección de conjuntos (D). 
Supóngase que se desea averiguar todos los clientes que 
tienen un préstamo concedido y una cuenta abierta. Uti¬ 
lizando la intersección de conjuntos se puede escribir 

n nombre-cliente ( prestatario ) fl H nombre . cl¡ente ( ÍmpOSÍtOr ) 

La relación resultante de esta consulta aparece en la 
Figura 3.20. 

Obsérvese que se puede volver a escribir cualquier 
expresión del álgebra relacional utilizando la intersec¬ 
ción de conjuntos sustituyendo la operación intersección 
por un par de operaciones de diferencia de conjuntos, 
de la manera siguiente: 

ríls = r-(r-j) 

Por tanto, la intersección de conjuntos no es una ope¬ 
ración fundamental y no añade potencia al álgebra rela¬ 
cional. Sencillamente, es más conveniente escribir r D 
5 que r - (r - s). 

3.2.3.2. La operación reunión natural 

Suele resultar deseable simplificar ciertas consultas que 
exigen un producto cartesiano. Generalmente, las con¬ 
sultas que implican un producto cartesiano incluyen un 
operador selección sobre el resultado del producto car¬ 
tesiano. Considérese la consulta «Ftallar los nombres de 
todos los clientes que tienen concedido un préstamo en 
el banco y averiguar el importe del mismo». En primer 
lugar se calcula el producto cartesiano de las relaciones 
prestatario y préstamo. Luego, se seleccionan las tupias 
que sólo atañen al mismo número-préstamo, seguidas 
por la proyección de nombre-cliente, número-préstamo 
e importe resultantes: 

^ nombre-cliente , préstamo.número-préstamo, importe 

( ®prestatario.número-préstamo = préstamo.número-préstamo 

(prestatario x préstamo )) 


' En el Apartado 3.3 se introducen las operaciones que extienden la 
potencia del álgebra relacional al tratamiento de los valores nulos y 
ios valores de agregación. 
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nombre-cliente 

Gómez 

Pérez 

Santos 


FIGURA 3.20. Clientes con una cuenta abierta y un 
préstamo en el banco 


La reunión natural es una operación binaria que per¬ 
mite combinar ciertas selecciones y un producto carte¬ 
siano en una sola operación. Se denota por el símbolo 
de la «reunión» ¡x . La operación reunión natural forma 
un producto cartesiano de sus dos argumentos, realiza 
una selección forzando la igualdad de los atributos que 
aparecen en ambos esquemas de relación y, finalmente, 
elimina los atributos duplicados. 

Aunque la definición de la reunión natural es com¬ 
pleja, la operación es sencilla de aplicar. Como ilustra¬ 
ción, considérese nuevamente el ejemplo «Averiguar 
los nombres de todos los clientes que tienen concedido 
un préstamo en el banco y averiguar su importe». Esta 
consulta puede expresarse utilizando la reunión natural 
de la manera siguiente: 

n nombre-cliente, número-préstamo, importe (prestatario IX pt ¿StaitlO ) 

Dado que los esquemas de prestatario y de préstamo 
(es decir, Esquema-prestatario y Esquema-préstamo) 
tienen en común el atributo número-préstamo , la ope¬ 
ración reunión natural sólo considera los pares de tupias 
que tienen el mismo valor de número-préstamo. Esta 
operación combina cada uno de estos pares en una sola 
tupia en la unión de los dos esquemas (es decir, nom¬ 
bre-cliente, nombre-sucursal, número-préstamo, im¬ 
porte). Después de realizar la proyección, se obtiene la 
relación mostrada en la Figura 3.21. 

Considérense dos esquemas de relación R y 5 que 
son, por supuesto, listas de nombres de atributos. Si se 
consideran los esquemas como conjuntos, en vez de 
como listas, se pueden denotar los nombres de los atri¬ 
butos que aparecen tanto en R como en S mediante R d 
S, y los nombres de los atributos que aparecen en R, en 
S o en ambos mediante R U 5. De manera parecida, los 
nombres de los atributos que aparecen en R pero no en 


nombre-cliente 

número-préstamo 

importe 

Fernández 

P-16 

1.300 

Gómez 

P-23 

2.000 

Gómez 

P-11 

900 

López 

P-15 

1.500 

Pérez 

P-93 

500 

Santos 

P-17 

1.000 

Sotoca 

P-14 

1.500 

Valdivieso 

P-17 

1.000 


FIGURA 3.21. Resultado de n nombre-cliente, número-préstamo, 

imporn,{prestatario IX préstamo). 


S se denotan por R - S, mientras que S - R denota los 
nombres de los atributos que aparecen en S pero no en 
R. Obsérvese que las operaciones unión, intersección y 
diferencia aquí operan sobre conjuntos de atributos, y 
no sobre relaciones. 

Ahora se está preparado para una definición formal 
de la reunión natural. Considérense dos relaciones r(R) 
y s(S). La reunión natural de r y de 5, denotada por r 
M i es una relación del esquema R U S definida for¬ 
malmente de la manera siguiente: 

r tx S = y s (o r Ai = s Ai A r Á2 = 
s.A 2 a ... a r.A TÍ = s.A n r x $) 

donde R Cl S = {A,, A 2 , ..., A„}. 

Como la reunión natural es fundamental para gran 
parte de la teoría y de la práctica de las bases de datos 
relaciónales, se ofrecen varios ejemplos de su uso. 

• Hallar los nombres de todas las sucursales con 
clientes que tienen una cuenta abierta en el banco 
y que viven en Peguerinos. 

^-nombre-sucursal (.^ciudad-cliente = «Peguerinos» ( cliente X 

cuenta IX impositor )) 

La relación resultante de esta consulta aparece en 
la Figura 3.22. 

Obsérvese que se escribió cliente X cuenta X 
impositor sin añadir paréntesis para especificar el 
orden en que se deben ejecutar las operaciones reu¬ 
nión natural de las tres relaciones. En el caso ante¬ 
rior hay dos posibilidades: 

— (cliente X cuenta) X impositor 

— cliente X ( cuenta X impositor) 

No se especificó la expresión deseada porque las 
dos son equivalentes. Es decir, la reunión natural 
es asociativa. 

• Hallar todos los clientes que tienen una cuenta 
abierta y un préstamo concedido en el banco. 

u nombre-diente (prestatario X impositor ) 

Obsérvese que en el Apartado 3.2.3.1 se escribió 
una expresión para esta consulta utilizando la inter¬ 
sección de conjuntos. Aquí se repite esa expresión. 

n nombre-diente ( prestatario ) fí U nombre _ clleníe ( impositor ) 


nombre-sucursal 

Galapagar 

Navacerrada 


FIGURA 3.22. Resultado de lA nom ^ re _ sucursa i(o c ¡ u( j g( j_ c ij ente = 
«peguerinos» (cliente X cuenta X impositor )). 
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La relación resultante de esta consulta se mostró ante¬ 
riormente en la Figura 3.20. Este ejemplo ilustra una 
realidad común del álgebra relacional: se pueden 
escribir varias expresiones del álgebra relacional 
equivalentes que sean bastante diferentes entre sí. 

• Sean r(R) y 5 (S) relaciones sin atributos en común; 
es decir, R D S = 0. (0 denota el conjunto vacío.) 
Por tanto, r tx s = r x s. 

La operación reunión zeta es una extensión de la ope¬ 
ración reunión natural que permite combinar una selec¬ 
ción y un producto cartesiano en una sola operación. 
Considérense las relaciones r(R) y s(S), y sea 0 un pre¬ 
dicado de los atributos del esquema R U S. La opera¬ 
ción reunión zeta r IX 0 5 se define de la manera 
siguiente: 

r IX g s = o g (r x s) 

3.2.3.3. La operación división 

La operación división, denotada por -f, resulta adecuada 
para las consultas que incluyen la expresión «para 
todos». Supóngase que se desea hallar a todos los clien¬ 
tes que tengan abierta una cuenta en todas las sucursa¬ 
les ubicadas en Arganzuela. Se pueden obtener todas 
las sucursales de Arganzuela mediante la expresión 

t 1 — ^nombre-sucursal ciudad-sucursal - «Arganzuela» (sUCUrSOl)) 

La relación resultante de esta expresión aparece en la 
Figura 3.23. 

Se pueden encontrar todos los pares ( nombre-cliente , 
nombre-sucursal) para los que el cliente tiene una cuenta 
en una sucursal escribiendo 

r 2 = ^nombre-cliente, nombre-sucursal (^POSitOr IX Clienta) 

La Figura 3.24 muestra la relación resultante de esta 
expresión. 

Ahora hay que hallar los clientes que aparecen en r 2 
con los nombres de todas las sucursales de r x . La ope¬ 
ración que proporciona exactamente esos clientes es la 
operación división. La consulta se formula escribiendo 

^nombre-cliente, nombre-sucursal {ímpOSÍtOr N Cuenta) 

~ n nombre-sucursal ciudad-sucursal = «Arganzuela» ( SllCUVSClt) ) 

El resultado de esta expresión es una relación que tiene 
el esquema ( nombre-cliente ) y que contiene la tupia 
(González). 


nombre-sucursal 

Centro 

Galapagar 


FIGURA 3.22. Resultado de n nomXjre _ sucursa i(o c ¡ u( j 3( j_ sucursg i = 
«Arganzuela» (sucursal)). 


nombre-cliente 

nombre-sucursal 

Abril 

Collado Mediano 

Gómez 

Becerril 

González 

Centro 

González 

Galapagar 

López 

Navacerrada 

Rupérez 

Moralzarzal 

Santos 

Galapagar 

Valdivieso 

Navacerrada 


FIGURA 3.24. Resultado de n nombre-cliente, nombre-sucursal 

(impositor X cuenta)). 


Formalmente, sean r(R) y s(S) relaciones y S C /?; es 
decir, todos los atributos del esquema S están también 
en el esquema R. La relación r -f .y es una relación del 
esquema R - S (es decir, del esquema que contiene todos 
los atributos del esquema R que no están en el esquema 
S). Una tupia t está en r -fs si y sólo si se cumplen estas 
dos condiciones: 

1. í está en LI fi _ s (r) 

2. Para cada tupia t s de 5 hay una tupia f, de r que 
cumple las dos condiciones siguientes: 

a. asi = asi 

b. t r [R -S] = t 

Puede resultar sorprendente descubrir que, dados una 
operación división y los esquemas de las relaciones, se 
puede, de hecho, definir la operación división en tér¬ 
minos de las operaciones fundamentales. Sean r(R) y 
s(S) dadas, con S QR: 

r + s = LI S _ s (r) - LI ñ _ s ((U R _ s (r) x s) - II A _ s s (rj) 

Para comprobar que esta expresión es verdadera, obsér¬ 
vese que n x _ s (r) da todas las tupias t que cumplen la 
primera condición de la definición de la división. La 
expresión del lado derecho del operador diferencia de 
conjuntos, 

H/j-s ((n ^_5 (r) x s) - I/,' v. v ( r ))’ 

sirve para borrar esas tupias que no cumplen la segunda 
condición de la definición de la división. Esto se logra 
de la manera siguiente. Considérese H A , s (/) x s. Esta 
relación está en el esquema R y empareja cada tupia de 
1I A , s (r) con cada tupia de . 9 . La expresión 1I A , s s (r) 
sólo reordena los atributos de r. 

Por tanto, (LI A _ S (r) x .v) — TI A , v s (r) genera los pares 
de tupias de I1 A _ s (r) y de 9 que no aparecen en r. Si 
una tupia f ■ está en 

IIr-s ((n A _5 (r) x s) - n A s (r)), 

hay alguna tupia t s de ,v que no se combina con la tupia 
tj para formar una tupia de r. Por tanto, t ¡ guarda un valor 
de los atributos R - S que no aparece en r f s. Estos 
valores son los que se eliminan de II A _ 5 (r). 
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3.2.3.4. La operación asignación 

En ocasiones resulta conveniente escribir una expresión 
del álgebra relacional por partes utilizando la asigna¬ 
ción a una variable de relación temporal. La operación 
asignación, denotada por actúa de manera parecida 
a la asignación de los lenguajes de programación. Para 
ilustrar esta operación, considérese la definición de la 
división dada en el Apartado 3.2.3.3. Se puede escribir 
rn-s como 

temp 1 

temp2 <- H R _ s ((templ x s) - II A s s (r)) 
resultado = temp 1 - templ 

La evaluación de una asignación no hace que se mues¬ 
tre ninguna relación al usuario. Por el contrario, el 


resultado de la expresión a la derecha de se asigna 
a la variable relación a la izquierda de Esta varia¬ 
ble relación puede utilizarse en expresiones posterio¬ 
res. 

Con la operación asignación se pueden escribir las 
consultas como programas secuenciales consistentes en 
una serie de asignaciones seguida de una expresión cuyo 
valor se muestra como resultado de la consulta. En las 
consultas del álgebra relacional la asignación siempre 
debe hacerse a una variable de relación intermedia. Las 
asignaciones a relaciones permanentes constituyen una 
modificación de la base de datos. Este asunto se discu¬ 
tirá en el Apartado 3.4. Obsérvese que la operación asig¬ 
nación no añade potencia alguna al álgebra. Resulta, sin 
embargo, una manera conveniente de expresar las con¬ 
sultas complejas. 


3.3. OPERACIONES DEL ÁLGEBRA RELACIONAL EXTENDIDA 


Las operaciones básicas del álgebra relacional se han 
ampliado de varias maneras. Una ampliación sencilla 
es permitir operaciones aritméticas como parte de la 
proyección. Una ampliación importante es permitir ope¬ 
raciones de agregación, como el cálculo de la suma de 
los elementos de un conjunto, o su media. Otra amplia¬ 
ción importante es la operación reunión externa , que 
permite a las expresiones del álgebra relacional traba¬ 
jar con los valores nulos que modelan la información 
que falta. 

3.3.1. Proyección generalizada 

La operación proyección generalizada amplía la ope¬ 
ración proyección permitiendo que se utilicen funcio¬ 
nes aritméticas en la lista de proyección. La operación 
proyección generalizada tiene la forma 


donde E es cualquier expresión del álgebra relacional y 
F { , F 2 , ..., F n son expresiones aritméticas que incluyen 
constantes y atributos en el esquema de E. Como caso 
especial la expresión aritmética puede ser simplemente 
un atributo o una constante. 

Por ejemplo, supóngase que se dispone de una rela¬ 
ción información-crédito , como se muestra en la Ligura 
3.25, que da el límite de crédito y el importe dispuesto 


nombre-cliente 

límite 

saldo-crédito 

Gómez 

2.000 

400 

López 

1.500 

1.500 

Pérez 

2.000 

1.750 

Santos 

6.000 

700 


FIGURA 3.25. La relación información-crédito. 


hasta el momento presente (el saldo-crédito de la 
cuenta). Si se desea averiguar el importe disponible por 
cada persona, se puede escribir la expresión siguiente: 

D nombre-cliente, límite - saldo-crédito ( ÍnformaCÍÓH-CrédÍtO ) 

El atributo resultante de la expresión límite - saldo-cré¬ 
dito no tiene un nombre. Se puede aplicar la operación 
renombramiento al resultado de la proyección genera¬ 
lizada para darle un nombre. Como conveniencia nota- 
cional, el renombramiento de atributos se puede 
combinar con la proyección generalizada como se ilus¬ 
tra a continuación: 

D nombre-cliente, (límite - saldo-crédito) as crédito-disponible 

( información-crédito ) 

Al segundo atributo de esta proyección generalizada se 
le ha dado el nombre crédito-disponible. En la Ligura 
3.26 se muestra el resultado de aplicar esta expresión a 
la relación de la Ligura 3.25. 

3.3.2. Funciones de agregación 

Las funciones de agregación son funciones que toman 
una colección de valores y devuelven como resultado 
un único valor. Por ejemplo, la función de agregación 


nombre-cliente 

crédito-disponible 

Gómez 

1.600 

López 

0 

Pérez 

250 

Santos 

5.300 


FIGURA 3.26. Resultado de 11 nombre-cliente, ¡límite-saldo-crédito) 
as crédito-disponible ( información-crédito). 
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sum toma un conjunto de valores y devuelve la suma 
de los mismos. Por tanto, la función sum aplicada a la 
colección 

{1, 1,3,4,4, 11} 

devuelve el valor 24. La función de agregación avg de¬ 
vuelve la media de los valores. Cuando se aplica al con¬ 
junto anterior devuelve el valor 4. La función de 
agregación count devuelve el número de elementos del 
conjunto, y devolvería 6 en el caso anterior. Otras fun¬ 
ciones de agregación habituales son min y max, que 
devuelven el valor mínimo y el máximo de la colección; 
en el ejemplo anterior devuelven 1 y 11, respectiva¬ 
mente. 

Las colecciones en las que operan las funciones de 
agregación pueden tener valores repetidos; el orden en 
el que aparezcan los valores no tiene importancia. Estas 
colecciones se denominan multiconjuntos. Los con¬ 
juntos son un caso especial de los multiconjuntos, en 
los que sólo hay una copia de cada elemento. 

Para ilustrar el concepto de agregación se utilizará 
la relación trabajo-por-horas descrita en la Figura 3.27, 
que muestra los empleados a tiempo parcial. Supóngase 
que se desea averiguar la suma total de los sueldos de 
los empleados del banco a tiempo parcial. La expresión 
del álgebra relacional para esta consulta es: 

Qsum {SU eido)(trabajo-por-horas) 

El símbolo Q es la letra G en el tipo de letra caligráfico; 
se lee «G caligráfica». La operación del álgebra rela¬ 
cional (j significa que se debe aplicar agregación, y el 
subíndice indica la operación de agregación a aplicar. 
El resultado de la expresión anterior es una relación con 
un único atributo, que contiene una sola fila con un valor 
correspondiente a la suma de los sueldos de todos los 
trabajadores que trabajan en el banco a tiempo parcial. 

Hay casos en los que se deben borrar los valores repe¬ 
tidos antes de calcular una función de agregación. Si se 
desean borrar los valores repetidos hay que utilizar los 
mismos nombres de funciones que antes, con la cadena 
de texto «distinct» precedida de un guión añadida al 
final del nombre de la función (por ejemplo, count-dis- 
tinct). Un ejemplo se da en la consulta «Averiguar el 
número de sucursales que aparecen en la relación tra¬ 


nombre-empleado 

nombre-sucursal 

sueldo 

González 

Centro 

1.500 

Díaz 

Centro 

1.300 

Jiménez 

Centro 

2.500 

Catalán 

Leganés 

1.600 

Cana 

Leganés 

1.500 

Cascallar 

Navacerrada 

5.300 

Fernández 

Navacerrada 

1.500 

Ribera 

Navacerrada 

1.300 


FIGURA 3.27. La relación trabajo-por-horas. 


bajo-por-horas». En este caso, el nombre de cada sucur¬ 
sal sólo se cuenta una vez, independientemente del 
número de empleados que trabajen en la misma. Esta 
consulta se escribe de la manera siguiente: 

(/count-distinctfnombre-.swcMrsaO {trClbcijO-pOr-horas) 

Para la relación mostrada en la Figura 3.27 el resultado 
de esta consulta es el valor 3. 

Supóngase que se desea hallar la suma total de suel¬ 
dos de todos los empleados a tiempo parcial en cada 
sucursal del banco por separado, en lugar de hallar la 
suma de sueldos de todo el banco. Para ello hay que 
dividir la relación trabajo-por-horas en grupos basa¬ 
dos en la sucursal y aplicar la función de agregación a 
cada grupo. 

La expresión siguiente obtiene el resultado deseado 
utilizando el operador de agregación Q\ 

nombre-sucursal Qsum (sueldo) ( trabajo-por-horas ) 

El atributo nombre-sucursal subíndice a la izquierda 
de G indica que la relación de entrada trabajo-por- 
horas debe dividirse en grupos de acuerdo con el valor 
de nombre-sucursal. Los grupos resultantes se mues¬ 
tran en la Figura 3.28. La expresión sum {sueldo) en 
el subíndice derecho de Q indica que, para cada grupo 
de tupias (es decir, para cada sucursal) hay que apli¬ 
car la función de agregación sum al conjunto de valo¬ 
res del atributo sueldo. La relación resultante consiste 
en las tupias con el nombre de la sucursal y la suma 
de los sueldos de la sucursal, como se muestra en la 
Figura 3.29. 

La forma general de la operación de agregación C] 
es la siguiente: 

G h G 2 . G n GfmO. f 2 (A 2 ), .... F m (A m ) ( E ) 

donde E es cualquier expresión del álgebra relacional; 
Gj, G 2 , ...,G n constituye una lista de atributos que indi¬ 
can cómo se realiza la agrupación, cada F¡ es una fun¬ 
ción de agregación y cada A¡ es el nombre de un atributo. 
El significado de la operación se define de la manera 
siguiente. Las tupias en el resultado de la expresión E 
se dividen en grupos tales que 


nombre-empleado 

nombre-sucursal 

sueldo 

González 

Centro 

1.500 

Díaz 

Centro 

1.300 

Jiménez 

Centro 

2.500 

Catalán 

Leganés 

1.600 

Cana 

Leganés 

1.500 

Cascallar 

Navacerrada 

5.300 

Fernández 

Navacerrada 

1.500 

Ribera 

Navacerrada 

1.300 


FIGURA 3.28. La relación trabajo-por-horas después de la 
agrupación. 
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nombre-sucursal 

suma de sueldos 

Centro 

5.300 

Leganés 

3.100 

Navacerrada 

8.100 


FIGURA 3.29. RGSultado do nom b r e-sucursailjsum(sue\do) (tra 
bajo-por-horas ). 


1. Todas las tupias del grupo tienen los mismos valo¬ 
res para G,, G 2 , .. G n . 

2. Las tupias de grupos diferentes tienen valores 
diferentes para G { , G 2 , ..., G n . 

Por tanto, los grupos pueden identificarse por el valor 
de los atributos G,, G 2 , G„. Para cada grupo (gj, 

g 2 , ■■■, g„) el resultado tiene una tupia (g„ g 2 , g,„ 

«j, a 2 , ..., a m ) donde, para cada i, a¡ es el resultado de 
aplicar la función de agregación F¡ al multiconjunto 
de valores del atributo A¡ en el grupo. 

Como caso especial de la operación de agregación, 
la lista de atributos G 1( G 2 , ..., G„ puede estar vacía, en 
cuyo caso sólo hay un grupo que contiene todas las 
tupias de la relación. Esto corresponde a la agregación 
sin agrupación. 

Volviendo al ejemplo anterior, si se deseara averi¬ 
guar el sueldo máximo de los empleados a tiempo par¬ 
cial de cada oficina, además de la suma de los sueldos, 
habría que escribir la expresión 

nombre-sucursal Qsum(sueldo), ma x(sueldo) (jb(lbcljl)-pOI'-JlOl'dS) 

Como en la proyección generalizada, el resultado de 
una operación de agregación no tiene nombre. Se puede 
aplicar la operación renombramiento al resultado para 
darle un nombre. Como conveniencia notacional, los 
atributos de una operación de agregación se pueden 
renombrar como se indica a continuación: 

nombre-sucursal ítsum {sueldo) as suma-sueldo,musí sueldo) as 
sueldo-máximo (trabajo-por-horas ) 

El resultado de la expresión se muestra en la Figura 3.30. 

3.3.3. Reunión externa 

La operación reunión externa es una ampliación de la 
operación reunión para trabajar con la información que 
falta. Supóngase que se dispone de relaciones con los 


nombre-sucursal 

suma-sueldo 

sueldo-máximo 

Centro 

5.300 

2.500 

Leganés 

3.100 

1.600 

Navacerrada 

8.100 

5.300 


FIGURA 3.30. Resultado de nombre-sucursal íisumísueldoi as suma- 
sueldo maxlsueldo) as sueldo-máximo ( trdbdjo-por-hords). 


siguientes esquemas, que contienen datos de emplea¬ 
dos a tiempo completo: 

empleado ( nombre-empleado, calle, ciudad ) 
trabajo-a-tiempo-completo ( nombre-empleado, 
nombre-sucursal, sueldo ) 

Considérense las relaciones empleado y trabajo-a- 
tiempo-completo mostradas en la Figura 3.31. Supón¬ 
gase que se desea generar una única relación con toda 
la información (calle, ciudad, nombre de la sucursal y 
sueldo) de los empleados a tiempo completo. Un posi¬ 
ble enfoque sería utilizar la operación reunión natural 
de la manera siguiente: 

empleado XI trabajo-a-tiempo-completo 

El resultado de esta expresión se muestra en la Figura 
3.32. Obsérvese que se ha perdido la información sobre 
la calle y la ciudad de residencia de Gómez, dado que 
la tupia que describe a Gómez no está presente en la 
relación trabajo-a-tiempo-completo’, de manera pare¬ 
cida, se ha perdido la información sobre el nombre de 
la sucursal y sobre el sueldo de Barea, dado que la tupia 
que describe a Barea no está presente en la relación 
empleado. 

Se puede utilizar la operación reunión externa para 
evitar esta pérdida de información. En realidad, esta 
operación tiene tres formas diferentes: reunión externa 
por la izquierda, denotada por nxi; reunión externa por 
la derecha, denotada por xc y reunión externa completa, 
denotada por xc. Las tres formas de la reunión externa 
calculan la reunión y añaden tupias adicionales al resul¬ 
tado de la misma. El resultado de las expresiones emple¬ 
ado 3xi trabajo-a-tiempo-completo, empleado xe 
trabajo-a-tiempo-completo y empleado xc trabajo-a- 
tiempo-completo se muestra en las Figuras 3.33, 3.34 y 
3.35, respectivamente. 

La reunión externa por la izquierda (x) toma 
todas las tupias de la relación de la izquierda que no 
coincidan con ninguna tupia de la relación de la dere¬ 
cha, las rellena con valores nulos en todos los demás 
atributos de la relación de la derecha y las añade al resul- 


nombre-empleado 

calle 

ciudad 

Segura 

Domínguez 

Gómez 

Valdivieso 

Tebeo 

Viaducto 

Bailón 

Fuencarral 

La Loma 
Villaconejos 
Alcorcón 
Móstoles 


nombre-empleado 

nombre-sucursal 

sueldo 

Segura 

Majadahonda 

1.500 

Domínguez 

Majadahonda 

1.300 

Barea 

Fuenlabrada 

5.300 

Valdivieso 

Fuenlabrada 

1.500 


FIGURA 3.31. Las relaciones empleado y trabajo-a-tiempo- 
completo. 


69 





















FUNDAMENTOS DE BASES DE DATOS 


nombre-empleado 

calle 

ciudad 

nombre-sucursal 

sueldo 

Segura 

Tebeo 

La Loma 

Majadahonda 

1.500 

Domínguez 

Viaducto 

Vlllaconejos 

Majadahonda 

1.300 

Valdivieso 

Fuencarral 

Móstoles 

Fuenlabrada 

1.500 


FIGURA 3.32. La relación empleado M trabajo-a-tiempo-completo. 


tado de la reunión natural. En la Figura 3.33 la tupia 
(Gómez, Badén, Alcorcón, nulo, nulo) es una tupia de 
este tipo. Toda la información de la relación de la 
izquierda se halla presente en el resultado de la reunión 
externa por la izquierda. 

La reunión externa por la derecha ( cc) es simé¬ 
trica de la reunión externa por la izquierda. Las tupias de 


la relación de la derecha que no coincidan con ninguna 
tupia de la relación de la izquierda se rellenan con valo¬ 
res nulos y se añaden al resultado de la reunión natural. 
En la Figura 3.34 la tupia (Barea, nulo, nulo, Fuenla- 
brada, 5.300) es una tupia de este tipo. Por tanto, toda la 
información de la relación de la derecha se halla presente 
en el resultado de la reunión externa por la derecha. 


nombre-empleado 

calle 

ciudad 

nombre-sucursal 

sueldo 

Segura 

Tebeo 

La Loma 

Majadahonda 

1.500 

Domínguez 

Viaducto 

Vlllaconejos 

Majadahonda 

1.300 

Valdivieso 

Fuencarral 

Móstoles 

Fuenlabrada 

1.500 

Gómez 

Bailón 

Alcorcón 

nulo 

nulo 


FIGURA 3.33. Resultado de empleado X trabajo-a-tiempo-completo. 


La reunión externa completa (tc) realiza estas dos 
operaciones, rellenando las tupias de la relación de la 
izquierda que no coincidan con ninguna tupia de la rela¬ 
ción de la derecha y las tupias de la relación de la dere¬ 
cha que no coincidan con ninguna tupia de la relación 
de la izquierda, y añadiéndolas al resultado de la reu¬ 
nión. En la Figura 3.35 se muestra el resultado de una 
reunión externa completa. 


Puesto que las operaciones de reunión pueden gene¬ 
rar resultados que contengan nulos, es necesario espe¬ 
cificar cómo deben manejar estos valores las operaciones 
del álgebra relacional. El Apartado 3.3.4 aborda este 
aspecto. 

Es interesante observar que las operaciones de reu¬ 
nión extema pueden expresar mediante las operaciones 
básicas del álgebra relacional. Por ejemplo, la opera- 


nombre-empleado 

calle 

ciudad 

nombre-sucursal 

sueldo 

Segura 

Tebeo 

La Loma 

Majadahonda 

1.500 

Domínguez 

Viaducto 

Vlllaconejos 

Majadahonda 

1.300 

Valdivieso 

Fuencarral 

Móstoles 

Fuenlabrada 

1.500 

Barea 

nulo 

nulo 

Fuenlabrada 

5.300 


FIGURA 3.34. Resultado de empleado XC trabajo-a-tiempo-completo. 


ción de reunión externa por la izquierda rw jse puede 
expresar como: 

(r x s) U (r - n x (r M s)) x {(nulo, ..., nulo)} 

donde la relación constante {(nulo ,..., nulo)} se encuen¬ 
tra en el esquema S -R. 


3.3.4. Valores nulos** 

En este apartado se define la forma en que las diferen¬ 
tes operaciones del álgebra relacional tratan los valores 
nulos y las complicaciones que surgen cuando los valo¬ 
res nulos participan en las operaciones aritméticas o en 


nombre-empleado 

calle 

ciudad 

nombre-sucursal 

sueldo 

Segura 

Tebeo 

La Loma 

Majadahonda 

1.500 

Domínguez 

Viaducto 

Vlllaconejos 

Majadahonda 

1.300 

Valdivieso 

Fuencarral 

Móstoles 

Fuenlabrada 

1.500 

Gómez 

Bailón 

Alcorcón 

nulo 

nulo 

Barea 

nulo 

nulo 

Fuenlabrada 

5.300 


FIGURA 3.35. Resultado de empleado 3C trabajo-a-tiempo-completo. 
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las comparaciones. Como se verá, a menudo hay varias 
formas de tratar los valores nulos y, como resultado, las 
siguientes definiciones pueden ser a veces arbitrarias. 
Las operaciones y las comparaciones con valores nulos 
se deberían evitar siempre que sea posible. 

Dado que el valor especial nulo indica «valor des¬ 
conocido o no existente», cualquier operación aritmé¬ 
tica (como +, -, * y /) que incluya valores nulos debe 
devolver un valor nulo. 

De manera similar, cualquier comparación (como 
<, <=, >, >= y que incluya un valor nulo se evalúa al 
valor especial desconocido; no se puede decir si el resul¬ 
tado de la comparación es cierto o falso, así que se dice 
que el resultado es el nuevo valor lógico desconocido. 

Las comparaciones que incluyan nulos pueden apa¬ 
recer dentro de expresiones booleanas que incluyan las 
operaciones y (conjunción), o (disyunción) y no (nega¬ 
ción). Se debe definir la forma en que estas operacio¬ 
nes tratan el valor lógico desconocido. 

• y: ( cierto y desconocido ) = desconocido ; (falso y 
desconocido) = falso-, (desconocido y desconocido) 
= desconocido. 

• o: (cierto o desconocido) = cierto-, (falso o desco¬ 
nocido) = desconocido-, (desconocido o descono¬ 
cido) = desconocido. 

• no: (no desconocido) = desconocido. 

Ahora es posible describir la forma en que las dife¬ 
rentes operaciones del álgebra relacional tratan los valo¬ 
res nulos. Nuestras definiciones siguen las usadas en el 
lenguaje SQL. 

• select: la operación selección evalúa el predicado 
P en <J P (E) sobre cada tupia de E. Si el predicado 
devuelve el valor cierto, se añade t al resultado. 
En caso contrario, si el predicado devuelve des¬ 
conocido o falso, t no se añade al resultado. 

• reunión: las reuniones se pueden expresar como 
un producto cartesiano seguido de una selección. 
Por tanto, la definición de la forma en que la selec¬ 
ción trata los nulos también define la forma en que 
la operación reunión trata los nulos. 

En una reunión natural r xi 5 se puede obser¬ 
var de la definición anterior que si dos tupias, t r G 


r y t s G s, tienen un valor nulo en un atributo 
común, entonces las tupias no casan. 

• proyección: la operación proyección trata los nulos 
como cualquier otro valor al eliminar duplicados. 
Así, si dos tupias del resultado de la proyección 
son exactamente iguales, y ambos tienen nulos en 
los mismos campos, se tratan como duplicados. 

La decisión es un tanto arbitraria porque sin 
saber cuál es el valor real no se sabe si los dos valo¬ 
res nulos son duplicados o no. 

• unión, intersección, diferencia: estas operaciones 
tratan los valores nulos al igual que la operación 
proyección; tratan las tupias que tienen los mismos 
valores en todos los campos como duplicados 
incluso si algunos de los campos tienen valores 
nulos en ambas tupias. 

El comportamiento es un tanto arbitrario, espe¬ 
cialmente en el caso de la intersección y la diferen¬ 
cia, dado que no se sabe si los valores reales (si 
existen) representados por los nulos son los mismos. 

• proyección generalizada: se describió la manera 
en que se tratan los nulos en las expresiones al prin¬ 
cipio del Apartado 3.3.4. Las tupias duplicadas que 
contienen valores nulos se tratan como en la ope¬ 
ración proyección. 

Cuando hay nulos en los atributos agregados, 
la operación borra los valores nulos del resultado 
antes de aplicar la agregación. Si el multiconjunto 
resultante está vacío, el resultado agregado es nulo. 

Obsérvese que el tratamiento de los valores 
nulos aquí es diferente que en las expresiones arit¬ 
méticas ordinarias; se podría haber definido el resul¬ 
tado de una operación de agregación como nulo si 
incluso sólo uno de los valores agregados es nulo. 
Sin embargo, esto significaría que un único valor 
desconocido en un gran grupo podría hacer que el 
resultado agregado sobre el grupo fuese nulo, y se 
perdería una gran cantidad de información útil. 

• reunión externa: las operaciones de reunión 
externa se comportan como las operaciones reu¬ 
nión, excepto sobre las tupias que no aparecen en 
el resultado. Estas tupias se pueden añadir al resul¬ 
tado (dependiendo de si la operación es nxi, txc o 
3xE) añadiendo nulos. 


3.4. MODIFICACIÓN DE LA BASE DE DATOS 


Hasta ahora hemos centrado la atención en la extrac¬ 
ción de información de la base de datos. En este apar¬ 
tado se abordará la manera de insertar, borrar o modificar 
información de la base de datos. 

Las modificaciones de la base de datos se expresan 
utilizando la operación asignación. Las asignaciones a 
las relaciones reales de la base de datos se realizan uti¬ 


lizando la misma notación que se describió para la asig¬ 
nación en el Apartado 3.2.3. 

3.4.1. Borrado 

Las solicitudes de borrado se expresan básicamente igual 
que las consultas. Sin embargo, en lugar de mostrar las 
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tupias al usuario, se eliminan de la base de datos las tupias 
seleccionadas. Sólo se pueden borrar tupias enteras; no 
se pueden borrar valores de atributos concretos. En el 
álgebra relacional los borrados se expresan mediante 

r *—r-E 

donde r es una relación y £ es una consulta del álgebra 
relacional. 

He aquí varios ejemplos de solicitudes de borrado 
del álgebra relacional: 

• Borrar todas las cuentas de Gómez. 

impositor «- impositor - O nombre . cliente 
= «Gómez» (impositor) 

• Borrar todos los préstamos con importes entre 0 y 
50. 

préstamo «- préstamo - o importe > 0 and ¡mporte 
< 50 ( préstamo) 

• Borrar todas las cuentas de las sucursales sitas en 
Getafe. 

r l ^ciudad-sucursal = «Getafe» {cuenta N SUCUrSül ) 

^2 ^ nombre-sucursal, número-cuenta, saldo 1) 

cuenta cuenta - r 2 

Obsérvese que en el último ejemplo se simplificó 
la expresión utilizando la asignación a las relacio¬ 
nes temporales (r ¡ y r 2 ). 

3.4.2. Inserción 

Para insertar datos en una relación hay que especificar 
la tupia que se va a insertar o escribir una consulta cuyo 
resultado sea un conjunto de tupias que vayan a inser¬ 
tarse. Evidentemente, el valor de los atributos de las 
tupias insertadas deben ser miembros del dominio de 
cada atributo. De manera parecida, las tupias insertadas 
deben ser de la aridad correcta. En el álgebra relacional 
las inserciones se expresan mediante 

r«-cU£ 

donde r es una relación y £ es una expresión del álge¬ 
bra relacional. La inserción de una sola tupia se expresa 
haciendo que £ sea una relación constante que contiene 
una tupia. 

Supóngase que se desea insertar el hecho de que 
Gómez tiene 1.200 € en la cuenta C-973 en la sucursal 
de Navacerrada. Hay que escribir 

cuenta cuenta U {(C-973, «Navacerrada», 1200)} 
impositor impositor U {(«Gómez», C-973)} 

De forma más general, puede que se desee insertar 
tupias de acuerdo con el resultado de una consulta. 


Supóngase que se desea ofrecer una nueva cuenta de 
ahorro con 200 € como regalo a todos los clientes con 
préstamos concedidos en la sucursal de Navacerrada. 
Sea el número de préstamo el que se utilice como número 
de cuenta de esta cuenta de ahorro. Hay que escribir 

r i nombre-sucursal = «Navacerrada» (prestatario M préstamo)) 

^2 ^ ^-nombre-sucursal, número-préstamo i?" 1) 

cuenta <— cuenta U (r 2 x {(200)}) 

impOSitOr impositor U n nombre . cliente , númem -préstamo{ r \) 

En lugar de especificar las tupias como se hizo ante¬ 
riormente, se especifica un conjunto de tupias que se 
insertan en las relaciones cuenta e impositor. Cada tupia 
de la relación cuenta tiene el nombre-sucursal (Nava- 
cerrada), un número-cuenta (que es igual que el número 
de préstamo) y el saldo inicial de la nueva cuenta 
(200 €). Cada tupia de la relación impositor tiene como 
nombre-cliente el nombre del prestatario al que se le da 
la nueva cuenta y el mismo número de cuenta que la 
correspondiente tupia de cuenta. 

3.4.3. Actualización 

Puede que, en algunas situaciones, se desee modificar 
un valor de una tupia sin modificar todos los valores de 
la tupia. Se puede utilizar el operador proyección gene¬ 
ralizada para realizar esta tarea: 

r ^ n F l ,F 2 ,...,F n ( r ) 

donde cada £, es el í-ésimo atributo de r, si el i-ésimo 
atributo no está actualizado, o, si hay que actualizar el 
atributo, una expresión, que sólo implica constantes y 
los atributos de r, que da el nuevo valor del atributo. 

Si se desea seleccionar varias tupias de r y sólo actua¬ 
lizar esas mismas tupias, se puede utilizar la expresión 
siguiente, donde P denota la condición de selección que 
escoge las tupias que hay que actualizar: 

r n F b F 2 , ..., F n (°P M) U ( r ~ °P M) 

Para ilustrar el uso de la operación actualización 
supóngase que se realiza el pago de los intereses y que 
hay que aumentar todos los saldos en un 5 por ciento. 
Hay que escribir 

CUenta * ^nombre-sucursal, número-cuenta, saldo, saldo * 1.05 [clientü) 

Supóngase ahora que las cuentas con saldos supe¬ 
riores a 10.000 € reciben un interés del 6 por ciento, 
mientras que los demás reciben un 5 por ciento. Hay 
que escribir 

cuenta NC mldo r ¡ 06 [o saldo > 10000 [cuenta)) U 

cuenta ■«— n A , s NC mldo * ¡ 05 [o saldo s 1000 o [cuenta)) 

donde las abreviaturas NS y NC sustituyen a nombre- 
sucursal y a número-cuenta, respectivamente. 
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3.5. VISTAS 


En los ejemplos propuestos hasta ahora se ha operado 
en el nivel del modelo lógico. Es decir, se ha asumido 
que el conjunto de relaciones que se da son las relacio¬ 
nes reales guardadas en la base de datos. 

No es deseable que todos los usuarios puedan ver la 
totalidad del modelo lógico. Las consideraciones sobre 
la seguridad pueden exigir que algunos datos queden 
ocultos para los usuarios. Considérese una persona que 
necesita saber el número de préstamo de un cliente pero 
que no necesita ver el importe del préstamo. Esta per¬ 
sona debería ver una relación descrita en el álgebra rela- 
cional mediante 

H nombre-cliente, número-préstamo, nombre-sucursal 

(prestatario x préstamo ) 

Aparte de las consideraciones sobre la seguridad puede 
que se desee crear un conjunto personalizado de rela¬ 
ciones que se adapte mejor que el modelo lógico a la 
intuición de un usuario concreto. Por ejemplo, puede 
que un empleado del departamento de publicidad quiera 
ver una relación que conste de los clientes que tengan 
abierta una cuenta o concedido un préstamo en el banco 
y de las sucursales con las que trabajan. La relación que 
se crearía para ese empleado es 

^nombre-sucursal, nombre-cliente ( Ím P 0 ^ t0r Clienta) 

U n nombre-sucursal, nombre-cliente (Prestatario M préstamo ) 

Las relaciones que no forman parte del modelo lógico 
pero se hacen visibles a los usuarios como relaciones 
virtuales se denominan vistas. Se puede trabajar con 
gran número de vistas sobre cualquier conjunto dado de 
relaciones reales. 

3.5.1. Definición de vistas 

Las vistas se definen utilizando la instrucción create 
view. Para definir una vista hay que darle un nombre e 
indicar la consulta que la va a calcular. La forma de la 
instrucción create view es 

create view v as <expresión de consulta> 

donde <expresión de consulta> es cualquier expresión 
legal de consulta del álgebra relacional. El nombre de 
la vista se representa mediante v. 

Como ejemplo considérese la vista consistente en las 
sucursales y sus clientes. Supóngase que se desea que 
esta vista se denomine todos-los-clientes. Esta vista se 
define de la manera siguiente: 

create view todos-los-clientes as 

^nombre-sucursal. nombre-cliente (jmpOSÍtOl M Clienta ) 

U n nombre-sucursal, nombre-cliente (prestatario XI préstamo) 


Una vez se ha definido una vista se puede utilizar el 
nombre de la vista para hacer referencia a la relación 
virtual que genera la vista. Utilizando la vista todos-los- 
clientes se puede averiguar el nombre de todos los clien¬ 
tes de la sucursal de Navacerrada escribiendo 

^^nombre-cliente 'nombre-sucursal = «Navacerrada» 

( todos-los-clientes)) 

Recuérdese que en el Apartado 3.2.1 se escribió la 
misma consulta sin utilizar vistas. 

Los nombres de las vistas pueden aparecer en cual¬ 
quier lugar en el que pueda encontrarse el nombre de 
una relación, siempre y cuando no se ejecuten sobre las 
vistas operaciones de actualización. El asunto de las 
operaciones de actualización de las vistas se estudia en 
el Apartado 3.5.2. 

La definición de las vistas se diferencia de la opera¬ 
ción asignación del álgebra relacional. Supóngase que 
se define la relación rl de la manera siguiente: 

rl n nombre-sucursal, nombre-ctíentAí’npOSitOr XI CUeHtü) 

U n nombre-sucursal,nombre-clien, e{preStatarÍO X préStClMO) 

La operación asignación se evalúa una vez, y rl no cam¬ 
biará cuando se actualicen las relaciones impositor, 
cuenta, préstamo o prestatario. En cambio, si hay alguna 
modificación en estas relaciones, el conjunto de tupias 
de la vista todos-los-clientes también cambia. De manera 
intuitiva, en cualquier momento dado, el conjunto de 
tupias de la relación de vistas se define como el resul¬ 
tado de la evaluación de la expresión de consulta que 
define en ese momento la vista. 

Por tanto, si una relación de vistas se calcula y se 
guarda, puede quedar desfasada si las relaciones utili¬ 
zadas para definirla se modifican. En vez de eso, las vis¬ 
tas suelen implementarse de la manera siguiente. Cuando 
se define una vista, el sistema de la base de datos guarda 
la definición de la propia vista, en vez del resultado de la 
evaluación de la expresión del álgebra relacional que 
la define. Siempre que se utiliza una relación de vistas 
en una consulta, se sustituye por la expresión de con¬ 
sulta guardada. Por tanto, la relación de vistas vuelve a 
calcularse siempre que se evalúa la consulta. 

Algunos sistemas de bases de datos permiten que se 
guarden las relaciones de vistas, pero se aseguran de que, 
si las relaciones reales utilizadas en la definición de la 
vista cambian, la vista se mantenga actualizada. Estas 
vistas se denominan vistas materializadas. El proceso 
de mantener actualizada la vista se denomina manteni¬ 
miento de vistas, que se trata en el Apartado 14.5. Las 
aplicaciones en las que se utiliza frecuentemente una 
vista se benefician del uso de vistas materializadas, igual 
que las aplicaciones que demandan una rápida respuesta 
a ciertas consultas basadas en las vistas. Las ventajas de 
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la materialización de una vista para las consultas deben 
sopesarse frente a los costes de almacenamiento y la 
sobrecarga añadida por las actualizaciones. 

3.5.2. Actualizaciones mediante vistas 
y valores nulos 

Aunque las vistas son una herramienta útil para las con¬ 
sultas, plantean problemas signiñcativos si con ellas se 
expresan las actualizaciones, las inserciones o los borra¬ 
dos. La dificultad radica en que las modificaciones de 
la base de datos expresadas en términos de vistas deben 
traducirse en modificaciones de las relaciones reales en 
el modelo lógico de la base de datos. 

Para ilustrar el problema considérese un empleado 
que necesita ver todos los datos de préstamos de la rela¬ 
ción préstamo salvo importe. Sea préstamo-sucursal la 
vista dada al empleado. Se define esta vista como 

create view préstamo-sucursal as 

^^nombre-sucursal, número-préstamo ( préstamo } 


nulo) en prestatario y (nulo, nulo, 1900) en préstamo. 
Así, se obtienen las relaciones mostradas en la Figura 
3.36. Sin embargo, esta actualización no tiene el efecto 
deseado, dado que la relación de vistas información-cré¬ 
dito sigue sin incluir la tupia («González», 1900). Por 
tanto, no existe manera de actualizar las relaciones pres¬ 
tatario y préstamo utilizando valores nulos para obte¬ 
ner la actualización deseada de información-crédito. 

Debido a este tipo de problemas generalmente no se 
permiten las modificaciones en las relaciones de vistas 
excepto en casos limitados. Los diferentes sistemas de 
bases de datos especifican diferentes condiciones bajo 
las que se permiten actualizaciones sobre las vistas; 
véanse los manuales de cada sistema de bases de datos 
en particular para consultar más detalles. El problema 
general de la modificación de las bases de datos 
mediante las vistas ha sido objeto de numerosas inves¬ 
tigaciones. Las notas bibliográficas hacen mención de 
trabajos recientes sobre este asunto. 

3.5.3. Vistas definidas utilizando otras vistas 


Dado que se permite que los nombres de las vistas apa¬ 
rezcan en cualquier parte en la que estén permitidos los 
nombres de relaciones, el empleado puede escribir: 

préstamo-sucursal préstamo-sucursal 
U {(P-37, «Navacerrada»)} 

Esta inserción debe representarse mediante una inser¬ 
ción en la relación préstamo, dado que préstamo es la 
relación real a partir de la cual se genera la vista prés¬ 
tamo-sucursal. Sin embargo, para insertar una tupia en 
préstamo hay que tener algún valor para importe. Hay 
dos enfoques razonables para trabajar con esta inserción: 

• Rechazar la inserción y devolver al usuario un 
mensaje de error. 

• Insertar una tupia (P-37, «Navacerrada», nulo ) en 
la relación préstamo. 

Otro problema resultante de la modificación de la 
base de datos mediante las vistas aparece en una vista 
como la siguiente: 

create view información-crédito as 

n nombre-cliente,impar, e(PreStatariO N préstamo ) 

Esta vista da una lista del importe de cada préstamo 
que tenga concedido cualquier cliente del banco. Con¬ 
sidérese la inserción siguiente realizada mediante esta 
vista: 

información-crédito <— información-crédito 
U {(«González», 1900)} 

El único método posible de insertar tupias en las rela¬ 
ciones prestatario y préstamo es insertar («González», 


En el Apartado 3.5.1 se mencionó que las relaciones de 
vistas pueden aparecer en cualquier lugar en que pueda 
hacerlo el nombre de una relación, salvo las restriccio¬ 
nes en el uso de vistas en expresiones para la actualiza¬ 
ción. Por tanto, se pueden utilizar vistas en la expresión 
que define otra vista. Por ejemplo, se puede definir la 
vista cliente-navacerrada de la manera siguiente: 

create view cliente-navacerrada as 

^^nombre-cliente nombre-sucursal = «Navacerrada» 

(todos-los-clientes)) 

donde todos-los-clientes es, a su vez, una relación de 
vistas. 


número-préstamo 

nombre-sucursal 

importe 

P-11 

Collado Mediano 

900 

P-14 

Centro 

1.500 

P-15 

Navacerrada 

1.500 

P-16 

Navacerrada 

1.300 

P-17 

Centro 

1.000 

P-23 

Moralzarzal 

2.000 

P-93 

Becerril 

500 

nulo 

nulo 

1.900 


nombre-cliente 

número-préstamo 

Fernández 

P-16 

Gómez 

P-23 

Gómez 

P-11 

López 

P-15 

Pérez 

P-93 

Santos 

P-17 

Sotoca 

P-14 

Valdivieso 

P-17 

González 

nulo 
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FIGURA 3.36. Tupias insertadas en préstamo y en presta 
tario. 
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La expansión de vistas es una manera de definir el 
significado de las vistas definidas en términos de otras 
vistas. El procedimiento asume que las definiciones de 
vistas no son recursivas; es decir, ninguna vista se usa 
en su propia definición, bien directa o indirectamente a 
través de otras definiciones de vistas. Por ejemplo, si Vj 
se usa en la definición de v 2 , se usa en la definición de 
v 3 , y v 3 se usa en la definición de v,, entonces v¡, v 2 y v 3 
son recursivas. Las definiciones de vistas recursivas son 
útiles en algunos casos, y se volverá a ellas en el con¬ 
texto del lenguaje Datalog, en el Apartado 5.2. 

Sea la vista v, definida mediante una expresión e¡ que 
puede contener a su vez relaciones de vistas. Las relacio¬ 
nes de vistas representan a las expresiones que definen las 
vistas y, por tanto, se pueden sustituir por las expresiones 
que las definen. Si se modifica una expresión sustituyendo 
una relación de vistas por su definición, la expresión resul¬ 
tante puede seguir conteniendo otras relaciones de vistas. 
Por tanto, la expansión de vistas de una expresión repite 
la etapa de sustitución de la manera siguiente: 

repeat 

Buscar todas las relaciones de vistas v¡ de 
Sustituir la relación de vistas v¡ por la expresión 
que define v¡ 

until no queden más relaciones de vistas en e¡ 


Mientras las definiciones de las vistas no sean recursi¬ 
vas el bucle concluirá. Por tanto, una expresión e que 
contenga relaciones de vistas puede entenderse como 
la expresión resultante de la expansión de vistas de e, 
que no contiene ninguna relación de vistas. 

Como ilustración de la expansión de vistas considé¬ 
rese la expresión siguiente: 

nombre-cliente = «Martín» ( cliente-HaVOCerroda) 

El procedimiento de expansión de vistas produce ini¬ 
cialmente 

^ nombre-cliente = «Martín» (D nombre-cliente nombre-sucursal 

= «Navacerrada» ( todoS-loS-clietlteS))) 

luego produce 

®nombre-cliente = «Martín» (j^nombre-cliente ( ^nombre-sucursal 
= «Navacerrada» ( ^^-nombre-sucursal, nombre-cliente 

(impositor ix cuenta ) U U nombre _ s ^ ursal nombre _ cUente 
(prestatario XI préstamo)))) 

No hay más usos de las relaciones de vistas y concluye 
la expansión de vistas. 


3.6. EL CÁLCULO RELACIONAL DE TUPLAS 


Cuando escribimos una expresión del álgebra relacio- 
nal proporcionamos una serie de procedimientos que 
generan la respuesta a la consulta. El cálculo relacional 
de tupias, en cambio, es un lenguaje de consulta no pro- 
cedimental. Describe la información deseada sin dar 
un procedimiento específico para obtenerla. 

Las consultas se expresan en el cálculo relacional de 
tupias como 

{t I P(t)} 

es decir, son el conjunto de todas las tupias tales que el 
predicado P es cierto para t. Siguiendo la notación uti¬ 
lizada previamente, se utiliza t[A ] para denotar el valor 
de la tupia t en el atributo A y t E r para denotar que la 
tupia t está en la relación r. 

Antes de dar una definición formal del cálculo rela¬ 
cional de tupias se volverán a examinar algunas de las 
consultas para las que se escribieron expresiones de 
álgebra relacional en el Apartado 3.2. 

3.6.1. Consultas de ejemplo 

Supóngase que se desea averiguar nombre-sucursal, 
número-préstamo e importe de los préstamos superio¬ 
res a 1.200 €: 


{t I t G préstamo a ¡[importe] > 1200} 

Supóngase que sólo se desea obtener el atributo número- 
préstamo, en vez de todos los atributos de la relación 
préstamo. Para escribir esta consulta en el cálculo rela¬ 
cional de tupias hay que escribir una expresión para una 
relación del esquema ( número-préstamo). Se necesitan 
las tupias de ( número-préstamo ) tales que hay una tupia 
en préstamo con el atributo importe > 1200. Para expre¬ 
sar esta solicitud hay que utilizar el constructor «existe» 
de la lógica matemática. La notación 

3t£r(Q(t)) 

significa «existe una tupia t en la relación r tal que el 
predicado Q(t) es verdadero». 

Utilizando esta notación se puede escribir la consulta 
«Averiguar el número de préstamo de todos los présta¬ 
mos por importe superior a 1.200 €» como 

{t I 3 s G préstamo (f[ número-préstamo ] 

= s[número-préstamo ] a s\importe] > 1200)} 

En español la expresión anterior se lee «el conjunto de 
todas las tupias t tales que existe una tupia 5 en la rela¬ 
ción préstamo para la que los valores de t y de s para el 
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atributo número-préstamo son iguales y el valor de 5 
para el atributo importe es mayor que 1.200 €». 

La variable tupia t sólo se define para el atributo 
número-préstamo, dado que es el único atributo para el 
que se especifica una condición para t. Por tanto, el resul¬ 
tado es una relación de ( número-préstamo ). 

Considérese la consulta «Averiguar el nombre de 
todos los clientes que tienen concedido un préstamo en 
la sucursal de Navacerrada». Esta consulta es un poco 
más compleja que las anteriores, dado que implica a dos 
relaciones: prestatario y préstamo. Como se verá, sin 
embargo, todo lo que necesita es que tengamos dos ins¬ 
trucciones «existe» en la expresión de cálculo relacio- 
nal de tupias, relacionadas mediante y (a). La consulta 
se escribe de la manera siguiente: 

{t I 3 ,v G prestatario (t\n limero - p rés ta mo\ = 
s[número-préstamo ] a 3 u G préstamo 
( u[número-préstamo] = s[número-préstamo] 
a u[nombre-sucursal] = «Navacerrada»))} 

En español esta expresión es «el conjunto de todas las 
tupias ( nombre-cliente ) para las que el cliente tiene un 
préstamo concedido en la sucursal de Navacerrada». La 
variable tupia u asegura que el cliente es prestatario de 
la sucursal de Navacerrada. La variable tupia s está res¬ 
tringida para que corresponda al mismo número de prés¬ 
tamo que 5 . El resultado de esta consulta se muestra en 
la Ligura 3.37. 

Para averiguar todos los clientes del banco que tie¬ 
nen concedido un préstamo, una cuenta abierta, o ambas 
cosas, se utilizó la operación unión del álgebra relacio- 
nal. En el cálculo relacional de tupias harán falta dos 
instrucciones «existe» relacionadas por o (v): 

[t I 3 s G prestatario (t[nombre-cliente] 

= s[nombre-cliente ]) v 3 u G impositor 
( t[nombre-cliente] = u[nombre-cliente ])} 

Esta expresión da el conjunto de todas las tupias de 
nombre-cliente tales que se cumple al menos una de las 
condiciones siguientes: 

• nombre-cliente aparece en alguna tupia de la rela¬ 
ción prestatario como prestatario del banco. 

• nombre-cliente aparece en alguna tupia de la rela¬ 
ción impositor como impositor del banco. 

Si algún cliente tiene concedido un préstamo y una 
cuenta abierta en el banco, ese cliente sólo aparece una 


nombre-cliente 

Fernández 

López 

FIGURA 3.37. Nombre de todos los clientes que tienen 
concedido un préstamo en la sucursal de Navacerrada. 


vez en el resultado, ya que la definición matemática de 
conjunto no permite elementos duplicados. El resultado 
de esta consulta se mostró previamente en la Figura 

3.12. 

Si sólo queremos conocer los clientes que tienen en 
el banco una cuenta y un préstamo, todo lo que hay que 
hacer es cambiar en la expresión anterior la o (v) por 
una y (a). 

{t I 3 s G prestatario (t\nombre-cliente\ 

= s[nombre-cliente ]) a 3 uG impositor 
(t[nombre-cliente] = u[nombre-cliente ])} 

El resultado de esta consulta se mostró en la Figura 3.20. 

Considérese ahora la consulta «Averiguar todos los 
clientes que tienen una cuenta abierta en el banco pero 
no tienen concedido ningún préstamo». La expresión 
del cálculo relacional de tupias para esta consulta es 
parecida a las expresiones que se acaban de ver, salvo 
el uso del símbolo no (->): 

{t I 3 u G impositor (t\nombre-cliente\ 

= u[nombre-cliente ]) a-> 3 s G prestatario 
( t[nombre-cliente] = s[nombre-cliente ])} 

La expresión del cálculo relacional de tupias ante¬ 
rior utiliza la instrucción 3 u G impositor (...) para exi¬ 
gir que el cliente tenga una cuenta abierta en el banco, 
y utiliza la instrucción i3sG prestatario (...) para 
borrar a aquellos clientes que aparecen en alguna tupia 
de la relación prestatario por tener un préstamo del 
banco. El resultado de esta consulta apareció en la Figura 

3.13. 

La consulta que se tomará ahora en consideración 
utiliza la implicación, denotada por =>. La fórmula 
P => Q e s lógicamente equivalente a -> P v Q. El uso 
de la implicación en lugar de no y o suele sugerir una 
interpretación más intuitiva de la consulta en español. 

Considérese la consulta que se utilizó en el Apartado 
3.2.3 para ilustrar la operación división: «Averiguar 
todos los clientes que tienen una cuenta en todas las 
sucursales sitas en Arganzuela». Para escribir esta con¬ 
sulta en el cálculo relacional de tupias se introduce el 
constructor «para todo», denotado por V. La notación 

VfGr(G(0) 

significa «Q es verdadera para todas las tupias t de la 
relación r». 

La expresión para la consulta se escribe de la manera 
siguiente: 

{t I 3 r G cliente ( r\nombre-cliente] 

= t[nombre-cliente] a (V u G sucursal (u\ciudad- 
sucursal] = «Arganzuela» => 3 s G impositor 
{t[nombre-cliente] = s\nombre-cliente] a 3 w 
G cuenta (w[número-cuenta] = s[número-cuentá] 
a w[nombre-sucursal] = u[nombre-sucursal]))))} 
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En español esta expresión se interpreta como «el con¬ 
junto de todos los clientes (es decir, las tupias t ( nom¬ 
bre-cliente )) tales que, para todas las tupias u de la 
relación sucursal, si el valor de u en el atributo ciudad- 
sucursal es Arganzuela, el cliente tiene una cuenta en 
la sucursal cuyo nombre aparece en el atributo nombre- 
sucursal de u». 

Nótese que hay una sutileza en la consulta anterior: 
si no hay ninguna sucursal en Arganzuela, todos los 
nombres de cliente satisfacen la condición. La primera 
línea de la expresión de consulta es crítica en este caso: 
sin la condición 

3 r G cliente ( r[nombre-c!iente ] = t[nombre-cliente] 

si no hay sucursal en Arganzuela, cualquier valor de t 
(incluyendo los valores que no son nombres de cliente 
en la relación cliente) valdría. 

3.6.2. Definición formal 

Ahora se tiene la preparación necesaria para una defi¬ 
nición formal. Las expresiones del cálculo relacional de 
tupias son de la forma 

{t\pm 

donde P es una fórmula. En una fórmula pueden apa¬ 
recer varias variables tupia. Se dice que una variable 
tupia es una variable libre a menos que esté cuantifi- 
cada mediante 3 o V. Por tanto, en 

t G préstamo a 3 .y G cliente (t[nombre-sucursal] 

= s[nombre-sucursal]) 

t es una variable libre. La variable tupia y se denomina 
variable ligada. 

Las fórmulas de cálculo relacional de tupias se cons¬ 
truyen con átomos. Los átomos tienen una de las for¬ 
mas siguientes: 

• sGr, donde y es una variable tupia y r es una rela¬ 
ción (no se permite el uso del operador f) 

• y[x] 0 u[y], donde s y u son variables tupias, x es 

un atributo en el que está definida y, y es un atri¬ 
buto en el que está definida u y 0 es un operador 
de comparación (<, <, =, >, >); es necesario que 

los atributos x e y tengan dominios cuyos miem¬ 
bros puedan compararse mediante 0 

• y f.v] 0 c, donde y es una variable tupia, x es un atri¬ 
buto en el que está definida y, 0 es un operador de 
comparación y c es una constante en el dominio 
del atributo x 

Las fórmulas se construyen a partir de los átomos 
utilizando las reglas siguientes: 

• Un átomo es una fórmula. 


• Si P l es una fórmula, también lo son -> P, y ( P¡). 

• Si P { y P 2 son fórmulas, también lo son P { v P 2 , 

P \ A Pi y P\ Pi- 

• Si Pfs) es una fórmula que contiene una variable 
tupia libre y, y r es una relación, 

3 y G r (P l (y)) y V y G r (P l (y)) 
también son fórmulas 

Igual que en el álgebra relacional, se pueden escri¬ 
bir expresiones equivalentes que no sean idénticas en 
apariencia. En el cálculo relacional de tupias estas equi¬ 
valencias incluyen las tres reglas siguientes: 

1. P { a P 2 es equivalente a —> (—' ( P t ) v -i (. P 2 )). 

2. V t G r (P l (t)) es equivalente a -i 3 t G r (-> P, ( t)). 

3. P l => P 2 es equivalente a -i (P { ) v P 2 . 

3.6.3. Seguridad de las expresiones 

Queda un último asunto por tratar. Las expresiones del 
cálculo relacional de tupias pueden generar relaciones 
infinitas. Supóngase que se escribió la expresión 

{t I -i (? G préstamo )} 

Hay infinitas tupias que no están en préstamo. La mayor 
parte de estas tupias contienen valores que ni siquiera 
aparecen en la base de datos. Resulta evidente que no 
se desea permitir ese tipo de expresiones. 

Para ayudar a definir las restricciones del cálculo 
relacional de tupias se introduce el concepto de domi¬ 
nio de una fórmula relacional de tupias, P. De manera 
intuitiva, el dominio de P, denotado por dom(P), es el 
conjunto de todos los valores a los que P hace referen¬ 
cia. Esto incluye a los valores mencionados en la propia 
P, así como a los valores que aparezcan explícitamente 
en P o en una o en varias relaciones cuyos nombres apa¬ 
rezcan en P. Así, el dominio de P es el conjunto de todos 
los valores que aparecen explícitamente en una o más 
relación cuyos nombres aparecen en P. Por ejemplo, 
dom(t G préstamo a t[importe] > 1200) es el conjunto 
que contiene a 1200 y el conjunto de todos los valores 
que aparecen en préstamo. Además, dom(~< (t G prés¬ 
tamo)) es el conjunto de todos los valores que aparecen 
en préstamo, dado que la relación préstamo se men¬ 
ciona en la expresión. 

Se dice que una expresión {t I P(t)} es segura si todos 
los valores que aparecen en el resultado son valores de 
dom(P). La expresión {t I -> (t G préstamo)} no es segura. 
Obsérvese que dom(p (/ G préstamo)) es el conjunto de 
todos los valores que aparecen en préstamo. Sin embargo, 
es posible tener una tupia t que no esté en préstamo que 
contenga valores que no aparezcan en préstamo. El resto 
de ejemplos de expresiones del cálculo relacional de 
tupias que se han escrito en este apartado son seguros. 
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3.6.4. Potencia expresiva de los lenguajes 

El cálculo relacional de tupias restringido a expresio¬ 
nes seguras es equivalente en potencia expresiva al 
álgebra relacional básica (con los operadores U, -, x, 
o y p, pero sin los operadores relaciónales extendidos 
tales como la proyección generalizada G y las opera¬ 
ciones de reunión externa). Por tanto, para cada expre¬ 
sión del álgebra relacional hay una expresión 
equivalente del cálculo relacional de tupias, y para 


cada expresión del cálculo relacional de tupias hay una 
expresión equivalente del álgebra relacional. No se 
probará aquí esta afirmación; las notas bibliográficas 
contienen referencias a la demostración. Algunas par¬ 
tes de la misma se incluyen en los ejercicios. El cálculo 
relacional de tupias no tiene ningún equivalente de 
la operación agregación, pero se puede extender para 
contenerla. La extensión del cálculo relacional de 
tupias para manejar las expresiones aritméticas es sen¬ 
cilla. 


3.7. EL CÁLCULO RELACIONAL DE DOMINIOS** 


Hay una segunda forma de cálculo relacional denomi¬ 
nada cálculo relacional de dominios. Esta forma uti¬ 
liza variables de dominio que toman sus valores del 
dominio de un atributo, en vez de tomarlos de una tupia 
completa. El cálculo relacional de dominios, sin em¬ 
bargo, se halla estrechamente relacionado con el cálculo 
relacional de tupias. 

3.7.1. Definición formal 

Las expresiones del cálculo relacional de dominios son 
de la forma 

{< x lt x 2 , x n > I P(x u x 2 , ..., x„)} 

donde x¡, x 2 , ..., x n representan las variables de domi¬ 
nio, P representa una fórmula compuesta de átomos, 
como era el caso en el cálculo relacional de tupias. Los 
átomos del cálculo relacional de dominios tienen una 
de las formas siguientes: 

• < x¡, x 2 , ... , x n > G r, donde r es una relación con n 
atributos y Xj, x 2 , x n son variables de dominio 
o constantes de dominio. 

• x © y, donde x e y son variables de dominio y 0 

es un operador de comparación (<, <, =, >, >). 

Se exige que los atributos x e y tengan dominios 
que puedan compararse mediante 0. 

• x 0 c, donde x es una variable de dominio, 0 es 
un operador de comparación y c es una constante 
del dominio del atributo para el que x es una varia¬ 
ble de dominio. 

Las fórmulas se construyen a partir de los átomos uti¬ 
lizando las reglas siguientes: 

• Un átomo es una fórmula. 

• Si P { es una fórmula, también lo son ~>P l y (Pi). 

• Si í*! y P 2 son fórmulas, también lo son P ] v P 2 , 
P { a P 2 y P { => P 2 . 


• Si P x (x) es una fórmula en x, donde x es una varia¬ 
ble de dominio, 

3 x < (P | (x)) y V x (P¡ (x)) 

también son fórmulas 

Como notación abreviada se escribe 
3 a, b, c ( P(a , b, c)) 

en lugar de 

3 a (3 b (3 c ( P(a , b, c)))) 

3.7.2. Consultas de ejemplo 

Ahora se van a aportar consultas del cálculo relacional 
de dominios para los ejemplos considerados anterior¬ 
mente. Obsérvese la similitud de estas expresiones con 
las expresiones correspondientes del cálculo relacional 
de tupias 

• Averiguar el nombre de la sucursal, el número de 
préstamo y el importe de los préstamos superio¬ 
res a 1.200 €: 

{< p, s, i > I < p, s, i > G préstamo a i > 1200} 

• Averiguar todos los números de préstamo de los 
préstamos por importe superior a 1.200 €: 

{< p > I 3 s, i (< p, s, i> G préstamo a i > 1200)} 

Aunque la segunda consulta tenga un aspecto muy 
parecido al de la que se escribió para el cálculo rela¬ 
cional de tupias, hay una diferencia importante. En el 
cálculo de tupias, cuando se escribe 3 .v para alguna 
variable tupia s, se vincula inmediatamente con una 
relación escribiendo 3 s G r. Sin embargo, cuando se 
escribe 3 .v en el cálculo de dominios, 5 no se refiere a 
una tupia, sino a un valor de dominio. Por tanto, el 
dominio de la variable 5 no está restringido hasta que 
la subfórmula p, s, i G préstamo restringe 5 a los nom- 
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bres de sucursal que aparecen en la relación préstamo. 
Por ejemplo: 

• Averiguar el nombre de todos los clientes que tie¬ 
nen concedido un préstamo en la sucursal de Nava- 
cerrada y averiguar el importe del préstamo: 

{< n, c > I 3 / (< n, p > G prestatario a 3 s (< p, 
s, i > E préstamo a s = «Navacerrada»))} 

• Averiguar el nombre de todos los clientes que tie¬ 
nen concedido un préstamo, una cuenta abierta, o 
ambas cosas, en la sucursal de Navacerrada: 

{< n > I 3 p (< n, p > G prestatario a 3 s, i 
(< p, s, i > G préstamo a s = «Navacerrada»)) 
v 3 c (< n, c > G impositor a 3 s,i 
(< c, s,i>E: cuenta a s = «Navacerrada»))} 

• Averiguar el nombre de todos los clientes que tie¬ 
nen una cuenta abierta en todas las sucursales sitas 
en Arganzuela: 

{< c > I 3 s, t (< c, s, t > G cliente) a V x, y, z 
(< x, y, z > G sucursal ) a y = «Arganzuela» => 
3 a, b (< x, a, b > G cuenta a 
(< c, a > G impositor ))} 

En español la expresión anterior se interpreta como 
«el conjunto de todas las tupias c ( nombre-cliente ) 
tales que, para todas las tupias x, y, z ( nombre- 
sucursal , ciudad-sucursal, activos ), si la ciudad de 
la sucursal es Arganzuela, las siguientes afirma¬ 
ciones son verdaderas»: 

— Existe una tupia de la relación cuenta con 
número de cuenta a y nombre de sucursal x 
— Existe una tupia de la relación impositor con 
cliente c y número de cuenta a 

3.7.3. Seguridad de las expresiones 

Ya se observó que en el cálculo relacional de tupias es 
posible escribir expresiones que pueden generar rela¬ 
ciones infinitas. Esto llevó a definir la seguridad de las 
expresiones de cálculo relacional de tupias. Se produce 
una situación parecida en el cálculo relacional de domi¬ 
nios. Las expresiones como 

{< p, s, i > l-i (< p, s, i > E préstamo)} 

no son seguras porque permiten valores del resultado 
que no están en el dominio de la expresión. 

En el cálculo relacional de dominios también hay 
que tener en cuenta la forma de las fórmulas dentro de 
las instrucciones «existe» y «para todo». Considérese 
la expresión 

{< x > I 3 y (< x, y G r) a 3 z (< x, z > G r) 
a P(x, z))} 


donde P es una fórmula que implica a x y a z- Se puede 
probar la primera parte de la fórmula, 3 y (< x, y G r), 
tomando en consideración sólo los valores de r. Sin 
embargo, para probar la segunda parte de la fórmula, 3 
z (-> (< x, z > G r) a P(x, z)), hay que tomar en consi¬ 
deración valores de z que no aparecen en r. Dado que 
todas las relaciones son finitas, no aparece en r un 
número infinito de valores. Por tanto, no resulta posi¬ 
ble en general probar la segunda parte de la fórmula 3 
z (-■ (< x, z > G r) a P(x, z)), hay que tomar en consi¬ 
deración valores de z que no aparecen en r. Dado que 
todas las relaciones son finitas, no aparece en r un 
número infinito de valores. Por tanto, no es posible en 
general probar la segunda parte de la fórmula sin tomar 
en consideración un número infinito de valores de z. En 
vez de eso, se añaden restricciones para prohibir expre¬ 
siones como la anterior. 

En el cálculo relacional de tupias se restringió cual¬ 
quier variable cuantificada existencialmente a variar 
sobre una relación concreta. Dado que no se hizo así en 
el cálculo de dominios, hay que añadir reglas a la defi¬ 
nición de seguridad para tratar los casos parecidos a los 
del ejemplo. Se dice que la expresión 

{< X,, x 2 , ..., x„ > I P(x„ x 2 , ..., x„)} 

es segura si se cumplen todas las condiciones siguien¬ 
tes: 

1. Todos los valores que aparecen en las tupias de 
la expresión son valores de dom(P). 

2. Para cada subfórmula «existe» de la forma 3 x 
(Pjíx)), la subfórmula es cierta si y sólo si hay un 
valor x en dom(P j) tal que P ,(x) es verdadero. 

3. Para cada subfórmula «para todo» de la forma 
V x (P,(x)), la subfórmula es verdadera si y sólo 
si Pj(x) es verdadero para todos los valores x 
de dom(P { ). 

El propósito de las reglas adicionales es asegurar 
que se puedan probar las subfórmulas «para todo» y 
«existe» sin tener que probar infinitas posibilidades. 
Considérese la segunda regla de la definición de segu¬ 
ridad. Para que 3 x (P^x)) sea verdadero sólo hay que 
encontrar una x para la que P { (x) lo sea. En general, 
habría que probar infinitos valores. Sin embargo, si la 
expresión es segura, se sabe que se puede restringir la 
atención a los valores de dom(P { ). Esta restricción 
reduce las tupias que hay que tomar en consideración 
a un número finito. 

La situación de las subfórmulas de la forma V x 
(P,(x)) es parecida. Para asegurar que V x (P^x)) es 
verdadero hay que probar en general todos los valores 
posibles, por lo que hay que examinar infinitos valo¬ 
res. Como antes, si se sabe que la expresión es segura, 
basta con probar Pj(x) para los valores tomados de 
dom(P j). 
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Todas las expresiones del cálculo relacional de domi¬ 
nios que se han incluido en las consultas de ejemplo de 
este apartado son seguras. 

3.7.4. Potencia expresiva de los lenguajes 

Cuando el cálculo relacional de dominios se restringe a 
expresiones seguras es equivalente en potencia expresiva 
al cálculo relacional de tupias restringido a expresiones 
seguras. Dado que se observó anteriormente que el cálculo 
relacional de tupias restringido es equivalente al álgebra 
relacional, los tres lenguajes siguientes son equivalentes: 


• El álgebra relacional básica (sin las operaciones 
extendidas) 

• El cálculo relacional de tupias restringido a expre¬ 
siones seguras 

• El cálculo relacional de dominios restringido a 
expresiones seguras 

El cálculo relacional de dominios tampoco tiene equi¬ 
valente para la operación agregación, pero se puede 
extender para contenerla, y su extensión para el trata¬ 
miento de expresiones aritméticas es sencilla. 


3.8. RESUMEN 


• El modelo de datos relacional se basa en un con¬ 
junto de tablas. El usuario del sistema de bases de 
datos puede consultar esas tablas, insertar nuevas 
tupias, borrar tupias y actualizar (modificar) las tupias. 
Hay varios lenguajes para expresar estas operaciones. 

• El álgebra relacional define un conjunto de opera¬ 
ciones algebraicas que operan sobre tablas y devuel¬ 
ven tablas como resultado. Estas operaciones se 
pueden combinar para obtener expresiones que expre¬ 
san las consultas deseadas. El álgebra define las ope¬ 
raciones básicas usadas en los lenguajes de consulta 
relaciónales. 

• Las operaciones del álgebra relacional se pueden divi¬ 
dir en : 

— Operaciones básicas 

— Operaciones adicionales que se pueden expresar 
en términos de las operaciones básicas 

— Operaciones extendidas, algunas de las cuales 
añaden mayor poder expresivo al álgebra rela¬ 
cional 

• Las bases de datos se pueden modificar con la inser¬ 
ción, el borrado y la actualización de tupias. Se usó 
el álgebra relacional con el operador de asignación 
para expresar estas modificaciones. 

• Los diferentes usuarios de una base de datos com¬ 
partida pueden aprovecharse de vistas individualiza¬ 
das de la base de datos. Las vistas son «relaciones 
virtuales» definidas mediante expresiones de consulta. 


• Las vistas son mecanismos útiles para simplificar las 
consultas a la base de datos, pero la modificación de 
la base de datos mediante las vistas puede tener con¬ 
secuencias potencialmente desventajosas. Por tanto, 
los sistemas de bases de datos restringen estrictamente 
las actualizaciones mediante vistas. 

• Por razones de eficiencia del procesamiento de las 
consultas, una vista puede estar materializada, es 
decir, la consulta se evalúa y el resultado se almacena 
físicamente. Cuando las relaciones de la base de datos 
se actualizan, la vista materializada se debe actuali¬ 
zar correspondientemente. 

• El cálculo relacional de tupias y el cálculo relacio¬ 
nal de dominios son lenguajes no procedimentales 
que representan la potencia básica necesaria en un len¬ 
guaje de consultas relaciónales. El álgebra relacional 
básica es un lenguaje procedimental que es equiva¬ 
lente en potencia a ambas formas del cálculo relacio¬ 
nal cuando se restringen a las expresiones seguras. 

• El álgebra relacional y los cálculos relaciónales son 
lenguajes rígidos, formales, que no resultan adecua¬ 
dos para los usuarios ocasionales de los sistemas de 
bases de datos. Los sistemas comerciales de bases de 
datos, por tanto, utilizan lenguajes con más «azúcar 
sintáctico». En los Capítulos 4 y 5 se tomarán en con¬ 
sideración los tres lenguajes comerciales más influ¬ 
yentes: SQL, que está basado en el álgebra relacional, 
QBE y Datalog, que están basados en el cálculo rela¬ 
cional de dominios. 
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TÉRMINOS DE REPASO 

• Agrupación 


— Intersección de conjuntos Cl 

• Álgebra relacional 


— Reunión natural IX 

• Cálculo relacional de dominios 

• Cálculo relacional de tupias 

• Clave externa 

— Relación referenciada 
— Relación referenciante 

• Claves 

• Definición de vistas 

• Dominio atómico 

• Diagrama de esquema 

• Ejemplar de la base de datos 

• 

Operaciones del álgebra relacional 

— Diferencia de conjuntos - 

— Producto cartesiano x 

— Proyección II 

— Renombramiento p 

— Selección o 

• 

— Unión U 

Operaciones del álgebra relacional extendida 

— Agregación G 

— Proyección generalizada II 

— Reunión externa 

• Ejemplar de la relación 


- Reunión externa completa ixc 

• Esquema de la base de datos 


- Reunión externa por la derecha >c 

• Esquema de la relación 


- Reunión externa por la izquierda nx 

• Expansión de vistas 

• 

Operación asignación 

• Lenguaje de consulta 

• 

Potencia expresiva de los lenguajes 

• Lenguaje procedimental 

• 

Relación 

• Lenguaje no procedimental 

• 

Seguridad de las expresiones 

• Modificación de la base de datos 

• 

Tabla 

— Actualización 

• 

Valor nulo 

— Borrado 

• 

Valores nulos 

— Inserción 

• 

Variable tupia 

• Multiconjuntos 

• 

Vistas 

• Operaciones adicionales 

• 

Vistas recursivas 

— División / 



EJERCICIOS 


3 . 1 . Diséñese una base de datos relacional para la oficina de 
registro de una universidad. La oficina conserva datos 
sobre cada curso, incluyendo el profesor, el número de 
estudiantes matriculados y la hora y el lugar de las cla¬ 
ses. Por cada pareja estudiante-curso se guarda una cali¬ 
ficación. 

3 . 2 . Descríbanse las diferencias de significado entre los tér¬ 
minos relación y esquema de la relación. Ilústrese la res¬ 
puesta haciendo referencia a la solución propuesta para 
el Ejercicio 3.1. 

3 . 3 . Diséñese una base de datos relacional correspondiente 
al diagrama E-R de la Figura 3.38. 

3 . 4 . En el Capítulo 2 se mostró la manera de representar los 
conjuntos de relaciones de varios a varios, de varios a 
uno, de uno a varios y de uno a uno. Expliqúese la manera 
en que las claves primarias ayudan a representar estos 
conjuntos de relaciones en el modelo relacional. 


3 . 5 . Considérese la base de datos relacional de la Figura 3.39. 
Dese una expresión del álgebra relacional, otra del 
cálculo relacional de tupias y una tercera del cálculo rela¬ 
cional de dominios para cada una de las consultas 
siguientes: 

a. Averiguar los nombres de todos los empleados que 
trabajan para el Banco Importante. 

b. Averiguar el nombre y la ciudad de residencia de 
todos los empleados que trabajan para el Banco 
Importante. 

c. Averiguar el nombre, la calle y la ciudad de resi¬ 
dencia de todos los empleados que trabajan para el 
Banco Importante y ganan más de 2.000.000 de 
pesetas anuales. 

d. Averiguar el nombre de todos los empleados de esta 
base de datos que viven en la misma ciudad que la 
compañía para la que trabajan. 
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FIGURA 3.38. Diagrama E-R. 


e. Averiguar el nombre de todos los empleados que viven 
en la misma ciudad y en la misma calle que sus jefes. 

f. Averiguar el nombre de todos los empleados de esta 
base de datos que no trabajan para el Banco Importante. 

g. Averiguar el nombre de todos los empleados que 
ganan más que cualquier empleado del Banco 
Pequeño. 

h. Supóngase que las compañías pueden estar instala¬ 
das en ciudades pequeñas. Hállense todas las com¬ 
pañías instaladas en cada ciudad en la que está 
instalado el Banco Pequeño. 

3 . 6 . Considérese la relación de la Figura 3.21, que muestra 
el resultado de la consulta «Averigüese el nombre de 
todos los clientes que tienen concedido un préstamo en 
el banco». Vuélvase a escribir la consulta para incluir no 
sólo el nombre, sino también la ciudad de residencia de 
cada cliente. Obsérvese que ahora el cliente Sotoca ya 
no aparece en el resultado, aunque en realidad tiene un 
préstamo concedido por el banco. 

a. Expliqúese el motivo de que Sotoca no aparezca en 
el resultado. 

b. Supóngase que se desea que Sotoca aparezca en el 
resultado. ¿Cómo habría que modificar la base de 
datos para conseguirlo? 

c. Una vez más, supóngase que se desea que Sotoca apa¬ 
rezca en el resultado. Escríbase una consulta utili¬ 
zando una reunión externa que cumpla esta condición 
sin que haya que modificar la base de datos. 

3 . 7 . Las operaciones de reunión externa amplían la opera¬ 
ción reunión natural de manera que las tupias de las rela¬ 
ciones participantes no se pierdan en el resultado de la 
reunión. Descríbase la manera en que la operación reu¬ 
nión zeta puede ampliarse para que las tupias de la rela¬ 
ción de la izquierda, las de la relación de la derecha o 
las de ambas relaciones no se pierdan en el resultado de 
una reunión zeta. 

empleado ( nombre-empleado , calle, ciudad) 
trabaja ( nombre-empleado , nombre-empresa, sueldo) 
empresa ( nombre-empresa , ciudad) 
jefe ( nombre-empleado . nombre-jefe) 

FIGURA 3.39. Base de datos relacional para los Ejercicios 

3.5 y 3.10. 


3 . 8 . Considérese la base de datos regional de la Figura 3.39. 
Dese una expresión del álgebra relacional para cada 
petición: 

a. Modificar la base de datos de manera que Santos 
viva ahora en Tres Cantos. 

b. Dar a todos los empleados del Banco Importante un 
aumento de sueldo del 10 por ciento. 

c. Dar a todos los jefes de la base de datos un aumento 
de sueldo del 10 por ciento. 

d. Dar a todos los jefes de la base de datos un aumento 
de sueldo del 10 por ciento, a menos que el sueldo 
resultante sea mayor que 100.000 €. En este caso, 
dar sólo un aumento del 3 por ciento. 

e. Borrar todas las tupias de los empleados de Banco 
Pequeño de la relación trabajo. 

3.9. Utilizando el ejemplo bancario, escríbanse consultas 
del álgebra relacional para averiguar las cuentas abier¬ 
tas por más de dos clientes: 

a. utilizando una función de agregación. 

b. sin utilizar funciones de agregación. 

3 . 10 . Considérese la base de datos relacional de la Figura 
3.38. Dese una expresión del álgebra relacional para 
cada una de las consultas siguientes: 

a. Averiguar la compañía con mayor número de em¬ 
pleados. 

b. Averiguar la compañía con la nómina (suma de suel¬ 
dos de sus empleados) más reducida. 

c. Averiguar las compañías cuyos empleados ganen 
un sueldo más elevado, en media, que el sueldo 
medio del Banco Importante. 

3 . 11 . Dense dos motivos por los que se puede decidir defi¬ 
nir una vista. 

3 . 12 . Cítense dos problemas importantes del procesamiento 
de la operación actualización expresadas en términos 
de vistas. 

3 . 13 . Sean los siguientes esquemas de relaciones: 

R = (A, B, C) 

S = (D, E, F) 

Sean las relaciones r(R) y ,v(.Sj. Dese una expresión del 
cálculo relacional de tupias que sea equivalente a cada 
una de las expresiones siguientes: 
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a. n a (R) 
b- o B= 17 (r) 

c. r x s 

d. n lf (o c=D (rxs)) 

3.14. Sea R - (A, B, C) y sean r, y r 2 relaciones del esquema 
R. Dese una expresión del cálculo relacional de domi¬ 
nios que sea equivalente a las expresiones siguientes: 

a. n A (rO 

b. o B=ll (r[) 

c. r l U r 2 

d. r¡ Í1 r 2 

e. r, - r 2 

f- n A B (rj) I>< n B c(r 2 ) 

3.15. Repítase el Ejercicio 3.5 usando el cálculo relacional 
de tupias y el de dominios. 

3.16. Sean R = (A, B) y S = (A, C) y sean r(R) y s(S) rela¬ 
ciones. Escríbanse expresiones del álgebra relacional 
equivalentes a las expresiones siguientes del cálculo 
relacional de dominios: 

a. {< a > I 3 b (< a, b > GE r a b = 17)} 

b. {< a, b, c> I < a, b > £ r a < a, c > GE s} 


c. {< a > I 3 b (< a, b > E r) v V c (3 d (< d, c > E s) 
=><ú,c>G{)} 

d. {< a > I 3 c (< a, c > E i) a 3 b¡, b 2 (< a, b x > G r 
a < c, ¿2 > G r a b x > í> 2 ))} 

3.17. Sea R = (A, B) y S = (A, C) y sean r(R) y í(S) rela¬ 
ciones. Utilizando la constante especial nulo, escrí¬ 
banse expresiones del cálculo relacional de tupias 
equivalentes a cada una de las expresiones siguien¬ 
tes: 

a. r XE .y 

b. r XE y 

c. r XI y 

3.18. Dense dos motivos por los que se puedan introducir 
valores nulos en la base de datos. 

3.19. Algunos sistemas permiten los valores nulos marca¬ 
dos. Un valor nulo marcado ± ; es igual a sí mismo, pero 
si i * j, ±, * _L ( . Una aplicación de valores nulos mar¬ 
cados debe permitir ciertas actualizaciones mediante 
el uso de vistas. Considérese la vista información-cré¬ 
dito (Apartado 3.5). Muéstrese la manera en que se pue¬ 
den utilizar los valores nulos marcados para permitir 
la inserción de la tupia («González», 1900) mediante 
información-crédito. 


NOTAS BIBLIOGRÁFICAS 


El modelo relacional fue propuesto por E. F. Codd del 
Laboratorio de investigación de San José de IBM a fina¬ 
les de los años sesenta [Codd, 1970]. Este trabajo motivó 
la concesión a Codd del prestigioso Premio Turing de 
la ACM en 1981 (Codd [1982]). 

Siguiendo el trabajo original de Codd se constituye¬ 
ron varios proyectos de investigación con el objetivo de 
crear sistemas de bases de datos relaciónales prácticos, 
incluyendo System R del Laboratorio de investigación 
de San José de IBM, Ingres en la Universidad de Cali¬ 
fornia en Berkeley, Query-by-Example en el Centro de 
investigación T. J. Watson de IBM ( IBM T. J. Watson 
Research Center) y el vehículo de prueba relacional 
(Peterlee Relational Test Ve hiele, PRTV) del Centro 
científico de IBM ( IBM Scientifc Center) en Peterlee, 
Reino Unido. System R se discute en Astrahan et al. 
[1976], Astrahan et al. [1979] y en Chamberlin et al. 
[1981]. Ingres se discute en Stonebraker [1980], Sto- 
nebraker [1986b] y en Stonebraker et al. [1976]. Query- 
by-Example se describe en Zloof [1977]. PRTV se 
describe en Todd [1976]. 

Actualmente están disponibles comercialmente 
numerosos productos de bases de datos relaciónales. 
Ejemplos de ello son DB2 de IBM, Ingres, Oracle, 
Sybase, Informix y Microsoft SQL Server. Ejemplos de 
productos de bases de datos para las computadoras per¬ 
sonales son Microsoft Access, dBase y FoxPro. La infor¬ 


mación sobre estos productos puede hallarse en sus 
manuales respectivos. 

En la mayor parte de los textos sobre bases de datos 
se incluye una discusión general del modelo relacional 
de datos. Atzeni y De Antonellis [1993] y Maier [1983] 
son textos dedicados exclusivamente al modelo rela¬ 
cional de datos. La definición original del álgebra rela¬ 
cional está en Codd [1970]; la del cálculo relacional de 
tupias en Codd [1972]. En Codd [1972] se encuentra 
una prueba formal de la equivalencia del cálculo rela¬ 
cional de tupias y del álgebra relacional. 

Se han propuesto varias ampliaciones del cálculo rela¬ 
cional. Klug [1982] y Escobar-Molano et al. [1993] des¬ 
criben ampliaciones para funciones de agregación 
escalares. En Codd [1979] se presentan ampliaciones del 
modelo relacional y discusiones sobre la incorporación 
de los valores nulos al álgebra relacional (el modelo 
RM/T), así como las la de las reuniones externas. Codd 
[1990] es un compendio de los trabajos de E. F. Codd sobre 
el modelo relacional. Las reuniones extemas también se 
discuten en Date [1993b]. El problema de la actualización 
de las bases de datos relaciónales mediante vistas se aborda 
en Bancilhon y Spyratos [1981], Cosmadakis y Papa- 
dimitriou [1984], Dayal y Bemstein [1978,1982] y Lan- 
gerak [1990]. El Apartado 14.5 trata el mantenimiento de 
las vistas materializadas, y las referencias a la literatu¬ 
ra sobre ello se pueden encontrar al final de ese capítulo. 
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PARTE 




BASES DE DATOS 
RELACIONALES 


U na base de datos relacional es un repositorio compartido de datos. Para 
hacer disponibles los datos de un base de datos relacional a los usua¬ 
rios hay que considerar varios aspectos. Uno es la forma en que los 
usuarios solicitan los datos: ¿cuáles son los diferentes lenguajes de consulta 
que usan? El Capítulo 4 trata el lenguaje SQL, que es el lenguaje de consulta 
más ampliamente usado actualmente. El Capítulo 5 trata otros dos lenguajes 
de consulta, QBE y Datalog, que ofrecen enfoques alternativos a la consulta de 
datos relaciónales. 

Otro aspecto es la integridad de datos y la seguridad; las bases de datos nece¬ 
sitan proteger los datos del daño provocado por los usuarios, ya sean intencio¬ 
nados o no. El componente de mantenimiento de la integridad de una base de 
datos asegura que las actualizaciones no violan las restricciones de integridad 
que hayan especificado sobre los datos. El componente de seguridad de una 
base de datos incluye la autenticación de usuarios y el control de acceso para 
restringir las posibles acciones de cada usuario. El Capítulo 6 trata los aspectos 
de integridad y seguridad. Estos aspectos se presentan independientemente del 
modelo de datos, pero se estudian en el contexto del modelo de datos relacio¬ 
nal para ejemplificarlos. Las restricciones de integridad forman la base del diseño 
de bases de datos relaciónales, que se estudian en el Capítulo 7. 

El diseño de bases de datos relaciónales —el diseño del esquema relacional— 
es el primer paso en la construcción de aplicaciones de bases de datos. El diseño 
de esquemas se trató informalmente en capítulos anteriores. Sin embargo, hay 
principios que se pueden usar para distinguir los buenos diseños de bases de 
datos. Se formalizan mediante varias «formas normales», que ofrecen diferen¬ 
tes compromisos entre la posibilidad de inconsistencias y la eficiencia de cier¬ 
tas consultas. El Capítulo 7 describe el diseño formal de esquemas relaciónales. 


CAPÍTULO 


4 


L os lenguajes formales descritos en el Capítulo 3 proporcionan una notación concisa para 
la representación de consultas. Sin embargo, los sistemas de bases de datos comerciales 
necesitan un lenguaje de consultas cómodo para el usuario. En este capítulo se estudia 
el lenguaje comercial de mayor influencia, SQL. SQL usa una combinación de álgebra relacio- 
nal y construcciones del cálculo relacional. 

Aunque el lenguaje SQL se considere un lenguaje de consultas, contiene muchas otras capa¬ 
cidades además de la consulta en bases de datos. Incluye características para definir la estruc¬ 
tura de los datos, para la modificación de los datos en la base de datos y para la especificación 
de restricciones de seguridad. 

No se pretende proporcionar un manual de usuario completo para SQL. Por el contrario, se 
presentan las construcciones y conceptos fundamentales de SQL. Las distintas implementa- 
ciones de SQL pueden diferenciarse en detalles, o pueden admitir sólo un subconjunto del len¬ 
guaje completo. 


4.1. INTRODUCCIÓN 


IBM desarrolló la versión original en su Laboratorio de 
Investigación de San José ( San José Research Center, 
actualmente Centro de Investigación de Almadén, Alma¬ 
dén Research Center). IBM implemento el lenguaje, 
originalmente denominado Sequel, como parte del pro¬ 
yecto System R, a principios de 1970. El lenguaje Sequel 
ha evolucionado desde entonces y su nombre ha pasa¬ 
do a ser SQL ( Structured Query Language, Lenguaje 
estructurado de consultas). Actualmente, numerosos 
productos son compatibles con el lenguaje SQL. SQL 
se ha establecido como el lenguaje estándar de bases de 
datos relaciónales. 

En 1986, ANSI ( American National Standards Ins- 
titute, Instituto Nacional Americano de Normalización) 
e ISO ( International Standards Organizaron, Organi¬ 
zación Internacional de Normalización), publicaron una 
norma SQL, denominada SQL-86. En 1987, IBM publi¬ 
có su propia norma de SQL corporativo, Interfaz de 
bases de datos para arquitecturas de aplicación a siste¬ 
mas ( Systems Application Architecture Database Inter- 
face, SAA-SQL). En 1989 se publicó una norma exten¬ 
dida para SQL denominada SQL-89 y actualmente los 
sistemas de bases de datos son normalmente compati¬ 
bles al menos con las características de SQL-89. La 
siguiente versión de la norma fue SQL-92 y la versión 
más reciente es SQL: 1999. Las notas bibliográficas pro¬ 
porcionan referencias a esas normas. 

En este apartado se presenta una visión general de 
SQL basada en la norma SQL-92 ampliamente imple- 
mentada. La norma SQL: 1999 es un superconjunto de 
la norma SQL-92; en este capítulo se tratan algunas 


características de SQL: 1999 y se proporciona un estu¬ 
dio más detallado en el Capítulo 9. Muchos sistemas de 
bases de datos soportan algunas de las nuevas cons¬ 
tructoras de SQL: 1999, aunque ningún sistema de bases 
datos actual soporta todas las nuevas constructoras. Tam¬ 
bién hay ser consciente de que algunos sistemas de bases 
de datos ni siquiera soportan todas las características de 
SQL-92 y de que muchas bases de datos proporcionan 
características no estándar que no se tratan aquí. 

El lenguaje SQL tiene varios componentes: 

• Lenguaje de definición de datos (LDD). El LDD 
de SQL proporciona órdenes para la definición de 
esquemas de relación, borrado de relaciones, cre¬ 
ación de índices y modificación de esquemas de 
relación. 

• Lenguaje interactivo de manipulación de datos 

(LMD). El LMD de SQL incluye un lenguaje de 
consultas, basado tanto en el álgebra relacional 
como en el cálculo relacional de tupias. Incluye 
también órdenes para insertar, borrar y modificar 
tupias de la base de datos. 

• Definición de vistas. El LDD de SQL incluye 
órdenes para la definición de vistas. 

• Control de transacciones. SQL incluye órdenes 
para la especificación del comienzo y final de tran¬ 
sacciones. 

• SQL incorporado y SQL dinámico. SQL diná¬ 
mico e incorporado define cómo se pueden incor¬ 
porar las instrucciones SQL en lenguajes de pro- 
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gramación de propósito general, tales como C, 
C++, Java, PL/I, Cobol, Pascal y Fortran. 

• Integridad. El LDD de SQL incluye órdenes para 
la especificación de las restricciones de integridad 
que deben satisfacer los datos almacenados en la 
base de datos. Las actualizaciones que violen las 
restricciones de integridad se rechazan. 

• Autorización. El LDD de SQL incluye órdenes 
para especificar derechos de acceso para las rela¬ 
ciones y vistas. 

En este capítulo se estudia el LMD y las caracterís¬ 
ticas básicas del LDD de SQL. También se describe bre¬ 
vemente SQL incorporado y dinámico, incluyendo las 
normas ODBC y JDBC para la interacción con una base 
de datos desde programas escritos en lenguajes C y Java. 
Las características de SQL que dan soporte a la integri¬ 
dad y autorización se describen en el Capítulo 6, mien¬ 
tras que el Capítulo 9 esboza las extensiones orientadas 
a objeto de SQL. 

Los ejemplos de este capítulo y posteriores se basa¬ 
rán en una empresa bancaria, con los siguientes esque¬ 
mas de relación: 


Esquema-sucursal = ( nombre-sucursal, 
ciudad-sucursal, activo) 

Esquema-cliente = ( nombre-cliente, calle-cliente, 
ciudad-cliente) 

Esquema-préstamo = ( número-préstamo, 
nombre-sucursal, importe) 

Esquema-prestatario = ( nombre-cliente, 
número-préstamo) 

Esquema-cuenta = ( número-cuenta, nombre- 
sucursal, saldo) 

Esquema-impositor = ( nombre-cliente, 
número-cuenta) 

Nótese que en este capítulo, como en el resto del tex¬ 
to, se usan nombres separados por guiones para los 
esquemas, relaciones y atributos para facilitar su lectu¬ 
ra. Sin embargo, en los sistemas SQL actuales, los guio¬ 
nes no son partes válidas de un nombre (se tratan como 
el operador menos). Una forma simple de traducir los 
nombres que se usan aquí a nombres SQL válidos es 
reemplazar todos los guiones por el símbolo de subra¬ 
yado («_»). Por ejemplo, se usa nombre_sucursal en 
lugar de nombre-sucursal. 


4.2. ESTRUCTURA BÁSICA 


Una base de datos relacional consiste en un conjunto de 
relaciones, a cada una de las cuales se le asigna un nom¬ 
bre único. Cada relación tiene una estructura similar a 
la presentada en el Capítulo 3. SQL permite el uso de 
valores nulos para indicar que el valor o bien es desco¬ 
nocido, o no existe. Se fijan criterios que permiten al 
usuario especificar a qué atributos no se puede asignar 
valor nulo, como estudiaremos en el Apartado 4.11. 

La estructura básica de una expresión SQL consiste 
en tres cláusulas: select, from y where. 

• La cláusula select corresponde a la operación pro¬ 
yección del álgebra relacional. Se usa para listar los 
atributos deseados del resultado de una consulta. 

• La cláusula from corresponde a la operación pro¬ 
ducto cartesiano del álgebra relacional. Lista las 
relaciones que deben ser analizadas en la evalua¬ 
ción de la expresión. 

• La cláusula where corresponde al predicado selec¬ 
ción del álgebra relacional. Es un predicado que 
engloba a los atributos de las relaciones que apa¬ 
recen en la cláusula from. 

Un hecho histórico desafortunado es que el término 
select tiene un significado diferente en SQL que en el álge¬ 
bra relacional. A continuación se resaltan las diferentes 
interpretaciones, a fin de minimizar la posible confusión. 

Una consulta típica en SQL tiene la forma 


select A,, A 2 ,...,A„ 
from r x , r 2 ,..., r m 

where P 

Cada Ai representa un atributo, y cada ri una relación. 
P es un predicado. La consulta es equivalente a la expre¬ 
sión del álgebra relacional 

U A x ,A 2 . A n (o p (u xr 2 x ... x r m )) 

Si se omite la cláusula where, el predicado P es cierto. 
Sin embargo, con diferencia a la expresión del álgebra 
relacional, el resultado de la consulta SQL puede con¬ 
tener varias copias de algunas tupias; este aspecto se 
analizará de nuevo en el Apartado 4.2.8. 

SQL forma el producto cartesiano de las relaciones 
incluidas en la cláusula from, lleva a cabo la selección 
del álgebra relacional usando el predicado de la cláu¬ 
sula where y entonces proyecta el resultado sobre los 
atributos de la cláusula select. En la práctica, SQL pue¬ 
de convertir la expresión en una forma equivalente que 
puede ser procesada más eficientemente. Las cuestio¬ 
nes relativas a la eficiencia se analizan en los Capítulos 
13 y 14. 

4.2.1. La cláusula select 

El resultado de una consulta SQL es, por supuesto, una 
relación. Considérese una consulta simple, usando el 
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ejemplo bancario, «Obtener los números de todas las 
sucursales en la relación préstamo»: 

select nombre-sucursal 
from préstamo 

El resultado es una relación consistente en el único atri¬ 
buto nombre-sucursal. 

Los lenguajes formales de consulta están basados en 
la noción matemática de que una relación es un con¬ 
junto. Así, nunca aparecen tupias duplicadas en las rela¬ 
ciones. En la práctica, la eliminación de duplicados con¬ 
sume tiempo. Sin embargo, SQL (como la mayoría de 
los lenguajes de consulta comerciales) permite dupli¬ 
cados en las relaciones, así como en el resultado de las 
expresiones SQL. Así, la consulta anterior listará cada 
nombre-sucursal una vez por cada tupia en la que apa¬ 
rece en la relación préstamo. 

En aquellos casos donde se quiera forzar la elimina¬ 
ción de duplicados, se insertará la palabra clave distinct 
después de select. Por lo tanto, se puede reescribir la 
consulta anterior como 

select distinct nombre-sucursal 
from préstamo 

si se desean eliminar los duplicados. 

Es importante resaltar que SQL permite usar la pala¬ 
bra clave all para especificar explícitamente que no se 
eliminan los duplicados: 

select all nombre-sucursal 
from préstamo 

Como de manera predeterminada se realiza la reten¬ 
ción de duplicados, de ahora en adelante no se usará la 
palabra clave all en los ejemplos. Para asegurar la elimi¬ 
nación de duplicados en el resultado de los ejemplos de 
consultas, se usará la cláusula distinct siempre que sea 
necesario. En la mayoría de las consultas donde no se uti¬ 
liza distinct, el número exacto de copias duplicadas de 
cada tupia que resultan de la consulta no es importante. 
Sin embargo, el número es importante en ciertas aplica¬ 
ciones; este aspecto se volverá a tratar en el Apartado 4.2.8. 

El símbolo asterisco «*» se puede usar para denotar 
«todos los atributos». Así, el uso de préstamo* en la 
cláusula select anterior indicaría que todos los atribu¬ 
tos de préstamo serían seleccionados. Una cláusula 
select de la forma select * indica que se deben selec¬ 
cionar todos los atributos de todas las relaciones que 
aparecen en la cláusula from. 

La cláusula select puede contener también expre¬ 
siones aritméticas que contengan los operadores, +, -, 
* y / operando sobre constantes o atributos de la tupias. 
Por ejemplo, la consulta 

select nombre-sucursal, número-préstamo, 
importe * 100 
from préstamo 


devolverá una relación que es igual que la relación prés¬ 
tamo, salvo que el atributo importe está multiplicado 
por 100. 

SQL también proporciona tipos de datos especia¬ 
les, tales como varias formas del tipo fecha y permite 
varias funciones aritméticas para operar sobre esos 
tipos. 

4.2.2. La cláusula where 

A continuación se ilustra con un ejemplo el uso de la 
cláusula where en SQL. Considérese la consulta «Obte¬ 
ner todos los números de préstamo para préstamos 
hechos en la sucursal con nombre Navacerrada, en los 
que el importe sea superior a 1.200 €». Esta consulta 
puede escribirse en SQL como 

select número-préstamo 
from préstamo 

where nombre-sucursal = ‘Navacerrada’ and 
importe > 1200 

SQL usa las conectivas lógicas and, or y not (en 
lugar de los símbolos matemáticos a, v y ->) en la cláu¬ 
sula where. Los operandos de las conectivas lógicas 
pueden ser expresiones que contengan los operadores 
de comparación <, <=, >, >=, = y o. SQL permite usar 
los operadores de comparación para comparar cadenas 
y expresiones aritméticas, así como tipos especiales, 
tales como el tipo fecha. 

SQL incluye un operador de comparación between 
para simplificar las cláusulas where que especifica que 
un valor sea menor o igual que un valor y mayor o igual 
que otro valor. Si se desea obtener el número de prés¬ 
tamo de aquellos préstamos por importes entre 90.000 € 
y 100.000 €, se puede usar la comparación between 
para escribir 

select número-préstamo 
from préstamo 

where importe between 90000 and 100000 
en lugar de 

select número-préstamo 
from préstamo 

where importe <= 100000 and importe >= 90000 

De forma análoga, se puede usar el operador de com¬ 
paración not between. 

4.2.3. La cláusula from 

Linalmente, se estudia el uso de la cláusula from. La 
cláusula from define por sí misma un producto carte¬ 
siano de las relaciones que aparecen en la cláusula. 
Escribir una expresión SQL para la reunión natural es 
una tarea relativamente fácil, puesto que la reunión natu- 
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ral se define en términos de un producto cartesiano, una 
selección y una proyección. 

La expresión del álgebra relacional se escribe como 
sigue: 

n nombre-cliente, númem-préstamojmporte (prestatario [XI f)f éstCUTlO ) 

para la consulta «Para todos los clientes que tienen un 
préstamo en el banco, obtener los nombres, números de 
préstamo e importes». Esta consulta puede escribirse en 
SQL como 

select nombre-cliente, prestatario.número-préstamo, 
importe 

from prestatario, préstamo 
where prestatario.número-préstamo 
= préstamo.número-préstamo 

Nótese que SQL usa la notación nombre-relación.nom¬ 
bre-atributo, como lo hace el álgebra relacional, para 
evitar ambigüedad en los casos en que un atributo apa¬ 
rece en el esquema de más de una relación. También se 
podría haber escrito prestatario.nombre-cliente en lugar 
de nombre-cliente, en la cláusula select. Sin embargo, 
como el atributo nombre-cliente aparece sólo en una de 
las relaciones de la cláusula from, no existe ambigüe¬ 
dad al escribir nombre-cliente. 

Se puede extender la consulta anterior y considerar 
un caso más complicado en el que se pide además qué 
clientes poseen un préstamo en la sucursal Navacerra- 
da: «Obtener los nombres, números de préstamo e 
importes de todos los clientes que tienen un préstamo 
en la sucursal Navacerrada». Para escribir esta consul¬ 
ta será necesario establecer dos restricciones en la cláu¬ 
sula where, relacionadas con la conectiva lógica and: 

select nombre-cliente, prestatario.número-préstamo, 
importe 

from prestatario, préstamo 
where prestatario.número-préstamo = 
préstamo.número-préstamo and 
nombre-sucursal= ‘Navacerrada’ 

SQL-92 incluye extensiones para llevar a cabo reu¬ 
niones naturales y reuniones externas en la cláusula 
from. Esto se estudiará en el Apartado 4.10. 

4.2.4. La operación renombramiento 

SQL proporciona un mecanismo para renombrar tanto 
relaciones como atributos. Para ello utiliza la cláusula 
as, que tiene la forma siguiente: 

nombre-antiguo as nombre-nuevo 

la cláusula as puede aparecer tanto en select como en 
from. 

Considérese de nuevo la consulta anterior: 


select distinct nombre-cliente, prestatario.número- 
préstamo, importe 
from prestatario, préstamo 
where prestatario.número-préstamo 
= préstamo.número-préstamo 

El resultado de esta consulta es una relación con los atri¬ 
butos siguientes: 

nombre-cliente, número-préstamo, importe. 

Los nombres de los atributos en el resultado se derivan 
de los nombres de los atributos de la relación que apa¬ 
rece en la cláusula from. 

Sin embargo, no se pueden derivar siempre los nom¬ 
bres de este modo. En primer lugar, dos relaciones que 
aparecen en la cláusula from pueden tener atributos con 
el mismo nombre, en cuyo caso, un nombre de atribu¬ 
to se duplica en el resultado. En segundo lugar, si se 
incluye una expresión aritmética en la cláusula select, 
los atributos resultantes no tienen el mismo nombre. 
Y en tercer lugar, incluso si un nombre de atributo se 
puede derivar de las relaciones base, como en el ejem¬ 
plo anterior, se puede querer cambiar el nombre del atri¬ 
buto en el resultado. Para todo ello, SQL proporciona 
una forma de renombrar los atributos de una relación 
resultado. 

Por ejemplo, si se quisiera renombrar el atributo 
número-préstamo, asociándole el nombre de id-présta¬ 
mo, se podría reescribir la consulta anterior del siguien¬ 
te modo 

select nombre-cliente, prestatario.número-préstamo 
as id-préstamo, importe 
from prestatario, préstamo 
where prestatario.número-préstamo = 
préstamo.número-préstamo 

4.2.5. Variables tupia 

La cláusula as es particularmente útil en la definición 
del concepto de variables tupia, como se hace en el 
cálculo relacional de tupias. Una variable tupia en SQL 
se debe asociar con una relación concreta. Las variables 
tupia se definen en la cláusula from mediante el uso de 
la cláusula as. Como ejemplo, a continuación se rees¬ 
cribe la consulta «Obtener los nombres y números de 
préstamo de todos los clientes que tienen un préstamo 
en el banco» como sigue 

select nombre-cliente, T.número-préstamo, S.importe 

from prestatario as T, préstamo as S 

where T.número-préstamo = S.número-préstamo 

Nótese que se define la variable tupia en la cláusula 
from, colocándola después del nombre de la relación a 
la cual está asociada y detrás de la palabra clave as (la 
palabra clave as es opcional). Al escribir expresiones 
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de la forma nombre-relación.nombre-atributo , el nom¬ 
bre de la relación es, en efecto, una variable tupia defi¬ 
nida implícitamente. 

Las variables tupia son de gran utilidad para com¬ 
parar dos tupias de la misma relación. Hay que recor¬ 
dar que, en los casos de este tipo, se puede usar la ope¬ 
ración renombramiento del álgebra relacional. Si se 
desea formular la consulta «Obtener los nombres de 
todas las sucursales que poseen un activo mayor que al 
menos una sucursal situada en Barcelona», se puede 
escribir la siguiente expresión SQL 

select distinct T.nombre-sucursal 

from sucursal as T, sucursal as S 

where T.activo > S.activo and S.ciudad-sucursal 
= ‘Barcelona’ 

Obsérvese que no se puede utilizar la notación sucur- 
sal.activo, puesto que no estaría claro a qué aparición 
de sucursal se refiere. 

SQL permite usar la notación (vj, v 2 ,..., v„) para desig¬ 
nar una tupia de aridad n que contiene los valores v,, v 2 , 
..., v„. Los operadores de comparación se pueden utili¬ 
zar sobre tupias, y el orden se define lexicográficamen¬ 
te. Por ejemplo (a^ a 2 ) < ( b¡ , b 2 ) es cierto si (a¡ < b¡) o 
si se cumple que (a, = b¡) a (a 2 < b 2 )\ análogamente, dos 
tupias son iguales si lo son todos sus atributos. 

4.2.6. Operaciones sobre cadenas 

SQL especifica las cadenas encerrándolas entre comi¬ 
llas simple, como ‘Navacerrada’, como se vio anterior¬ 
mente. Un carácter comilla que sea parte de una cade¬ 
na se puede especificar usando dos caracteres comilla; 
por ejemplo, la cadena «El carácter ‘ se puede ver en 
esta cadena» se puede especificar como ‘El carácter ” 
se puede ver en esta cadena’. 

La operación más usada sobre cadenas es el encaje 
de patrones, para el que se usa el operador like. Para la 
descripción de patrones se utilizan los dos caracteres 
especiales siguientes: 

• Tanto por ciento (%): El carácter % encaja con 
cualquier subcadena. 

• Subrayado (_): El carácter _ encaja con cualquier 
carácter. 

Los patrones son muy sensibles, esto es, los carac¬ 
teres en mayúsculas no encajan con los caracteres en 
minúscula, o viceversa. Para ilustrar el encaje de patro¬ 
nes, considérense los siguientes ejemplos: 

• ‘Nava%’ encaja con cualquier cadena que empie¬ 
ce con «Nava». 

• ‘%cer%’ encaja con cualquier cadena que conten¬ 
ga «cer» como subcadena, por ejemplo ‘Navace- 
rrada’, ‘Cáceres’ y ‘Becerril’. 


• ‘_’ encaja con cualquier cadena de tres carac¬ 

teres. 

• ‘_%’ encaja con cualquier cadena de al menos 

tres caracteres. 

Los patrones se expresan en SQL utilizando el opera¬ 
dor de comparación like. Considérese la consulta 
siguiente: «Obtener los nombres de todos los clientes 
cuyas calles contengan la subcadena ‘Mayor’». Esta 
consulta se podría escribir como sigue 

select nombre-cliente 
from cliente 

where calle-cliente like ‘%Mayor%’ 

Para que los patrones puedan contener los caracteres 
especiales patrón (esto es, % y _), SQL permite la espe¬ 
cificación de un carácter de escape. El carácter de esca¬ 
pe se utiliza inmediatamente antes de un carácter espe¬ 
cial patrón para indicar que ese carácter especial va a 
ser tratado como un carácter normal. El carácter de esca¬ 
pe para una comparación like se define utilizando la 
palabra clave escape. Para ilustrar esto, considérense 
los siguientes patrones, los cuales utilizan una barra 
invertida (\) como carácter de escape: 

• like ‘ab\%cd%’ escape ‘V encaja con todas las 
cadenas que empiecen por ab%cd . 

• like ‘ab\\cd%’ escape ‘V encaja con todas las cade¬ 
nas que empiecen por ab\cd . 

SQL permite buscar discordancias en lugar de concor¬ 
dancias utilizando el operador de comparación not like. 

SQL también proporciona una variedad de funcio¬ 
nes que operan sobre cadenas de caracteres, tales como 
la concatenación (usando «II»), la extracción de subca¬ 
denas, el cálculo de la longitud de las cadenas, la con¬ 
versión a mayúsculas y minúsculas, etc. SQL: 1999 tam¬ 
bién ofrece una operación similar to que proporciona 
un encaje de patrones más potente que la operación like; 
la sintaxis para especificar patrones es similar a la usa¬ 
da en Unix para expresiones regulares. 

4.2.7. Orden en la presentación de las tupias 

SQL ofrece al usuario cierto control sobre el orden en 
el cual se presentan las tupias de una relación. La cláu¬ 
sula order by hace que las tupias resultantes de una con¬ 
sulta se presenten en un cierto orden. Para listar en orden 
alfabético todos los clientes que tienen un préstamo en 
la sucursal Navacerrada se escribirá: 

select distinct nombre _cliente 
from prestatario, préstamo 
where prestatario.número-préstamo 

= préstamo.número-préstamo and 
nombre-sucursal = ‘Navacerrada’ 
order by nombre-cliente 
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De manera predeterminada la cláusula order by lista 
los elementos en orden ascendente. Para especificar el 
tipo de ordenación se puede incluir- la cláusula dése para 
orden descendente o ase para orden ascendente. Ade¬ 
más, se puede ordenar con respecto a más de un atri¬ 
buto. Si se desea listar la relación préstamo en orden 
descendente para importe. Si varios préstamos tienen el 
mismo importe, se ordenan ascendentemente según el 
número de préstamo. Esta consulta en SQL se escribe 
del modo siguiente: 

select * 

from préstamo 

order by importe dése, número-préstamo ase 

Para ejecutar una consulta que contiene la cláusula 
order by, SQL tiene que llevar a cabo una ordenación. 
Como ordenar un gran número de tupias puede ser cos¬ 
toso, es conveniente ordenar sólo cuando sea estricta¬ 
mente necesario. 

4.2.8. Duplicados 

La utilización de relaciones con duplicados se ha mos¬ 
trado útil en diversas situaciones. SQL no sólo define 
formalmente las tupias que están en el resultado de una 
consulta, sino también el número de copias de cada una 
de esas tupias que aparece en el resultado. La semán¬ 
tica de duplicados de una consulta SQL se puede defi¬ 
nir utilizando versiones de los operadores relaciónales 
para multiconjuntos. A continuación se definen las ver¬ 
siones multiconjunto de varios de los operadores del 
álgebra relacional. Dadas las relaciones multiconjunto 
r \ y r 2 . 


1. Si existen c { copias de la tupia t l en r¡, y q satis¬ 
face la selección a g , entonces hay c, copias de q 
en o g (r { ). 

2. Para cada copia de la tupia q en r l , hay una copia 
de la tupia II 4 (qj en IT//-,), donde II A (t x ) denota 
la proyección de la tupia única q. 

3. Si existen <q copias de la tupia q en r 1 y c 2 copias 
de la tupia t 2 en r 2 , entonces hay c l * c 2 copias de 
la tupia q.q en r, x r 2 . 

Por ejemplo, supóngase que las relaciones r, con 
esquema (A, B) y r 2 con esquema (C) son los multi¬ 
conjuntos siguientes: 

r 1 = {(l,a),(2,a)} r 2 = {(2), (3), (3)} 

Entonces, II B (r l ) sería {(a), (a)}, mientras que II B (r { ) 
x r 2 sería 

{(a, 2), (a,2), (a, 3), (rz,3), (a,3), (a,3)} 

Se puede ahora definir cuántas copias de cada tupia 
aparecen en el resultado de una consulta SQL. Una con¬ 
sulta SQL de la forma 

select Aj, A 2 , ..., A„ 
from r,, r 2 , r m 

where P 

es equivalente a la expresión del álgebra relacional 
U A u A 2 ,...,A n (°p( r i xr 2 x ... xrj) 

usando las versiones multiconjunto de los operadores 
relaciónales o, II y x. 


4.3. OPERACIONES SOBRE CONJUNTOS 


Las operaciones de SQL-92 unión, intersect y except 
operan sobre relaciones y corresponden a las operacio¬ 
nes del álgebra relacional U, fl y -. Al igual que la 
unión, intersección y diferencia de conjuntos en el álge¬ 
bra relacional, las relaciones que participan en las ope¬ 
raciones han de ser compatibles ; esto es, deben tener el 
mismo conjunto de atributos. 

A continuación se demuestra cómo se pueden for¬ 
mular en SQL varias de las consultas de ejemplo con¬ 
sideradas en el Capítulo 3 utilizando consultas que inclu¬ 
yen las operaciones unión, intersect y except de dos 
conjuntos. Los dos conjuntos utilizados serán: el con¬ 
juntos de todos los clientes que tienen una cuenta en el 
banco, que puede obtenerse con: 


y el conjunto de todos los clientes que tienen un prés¬ 
tamo en el banco, que puede obtenerse con: 

select nombre-cliente 
from prestatario 

A partir de ahora, las letras i y p se utilizarán para hacer 
referencia a las relaciones obtenidas como resultado de 
las dos consultas anteriores. 

4.3.1. La operación unión 

Para encontrar todos los clientes que poseen un présta¬ 
mo, una cuenta o las dos cosas en el banco, se escribirá: 


select nombre-cliente 
from impositor 
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unión 

(select nombre-cliente 
from prestatario) 

A diferencia de la cláusula select, la operación unión 
(unión) elimina duplicados automáticamente. Así, en la 
consulta anterior, si un cliente —por ejemplo, Santos— 
tiene varias cuentas o préstamos (o ambas cosas) en el 
banco, entonces Santos aparecerá sólo una vez en el 
resultado. 

Para conservar los duplicados, se utilizará unión all 
en lugar de unión: 

(select nombre-cliente 
from impositof) 

unión all 

(select nombre-cliente 
from prestatario) 

El número de tupias duplicadas en el resultado es igual 
al número total de duplicados que aparecen en i y p. Así, 
si Santos tuviese tres cuentas y dos préstamos en el ban¬ 
co, entonces en el resultado aparecerían cinco tupias 
con el nombre de Santos. 

4.3.2. La operación intersección 

Para encontrar todos los clientes que tienen tanto un 
préstamo como una cuenta en el banco, se escribirá: 

(select distinct nombre-cliente 
from impositor) 

intersect 

(select distinct nombre-cliente 
from prestatario) 

La operación intersect (intersección) elimina duplica¬ 
dos automáticamente. Así, en la consulta anterior, si un 
cliente —por ejemplo, Santos— tiene varias cuentas o 
préstamos (o ambas cosas) en el banco, entonces San¬ 
tos aparecerá solo una vez en el resultado. 

Para conservar los duplicados se utilizará intersect 
all en lugar de intersect: 

(select nombre-cliente 
from impositor) 


intersect all 

(select nombre-cliente 
from prestatario) 

El número de tupias duplicadas en el resultado es igual 
al mínimo número de duplicados que aparecen en i y p. 
Así, si Santos tuviese tres cuentas y dos préstamos en 
el banco, entonces en el resultado de la consulta apare¬ 
cerían dos tupias con el nombre de Santos. 

4.3.3. La operación excepto 

Para encontrar todos los clientes que tienen cuenta pero 
no tienen ningún préstamo en el banco se escribirá: 

(select distinct nombre-cliente 
from impositor) 

except 

(select distinct nombre-cliente 
from prestatario) 

La operación except (excepto) elimina duplicados auto¬ 
máticamente. Así, en la consulta anterior, una tupia con 
el nombre de Santos aparecerá en el resultado (exacta¬ 
mente una vez), sólo si Santos tiene una cuenta en el 
banco, pero no tiene ningún préstamo en el mismo. 

Para conservar los duplicados, se utilizará except all 
en lugar de except: 

(select nombre-cliente 
from impositor) 

except all 

(select nombre-cliente 
from prestatario) 

El número de copias duplicadas de una tupia en el resul¬ 
tado es igual al número de copias duplicadas de dicha tupia 
en i menos el número de copias duplicadas de la misma 
tupia en p, siempre que la diferencia sea positiva. Así, si 
Santos tuviese tres cuentas y un préstamo en el banco, 
entonces en el resultado aparecerían dos tupias con el nom¬ 
bre de Santos. Si, por el contrario, dicho cliente tuviese 
dos cuentas y tres préstamos en el banco, no habrá nin¬ 
guna tupia con el nombre de Santos en el resultado. 


4.4. FUNCIONES DE AGREGACIÓN 


Las funciones de agregación son funciones que toman 
una colección (un conjunto o multiconjunto) de valores 
como entrada y producen un único valor como salida. 
SQL proporciona cinco funciones de agregación pri¬ 
mitivas: 

• Media: avg 

• Mínimo: min 


• Máximo: max 

• Total: sum 

• Cuenta: count 


La entrada a sum y avg debe ser una colección de 
números, pero los otros operadores pueden operar sobre 
colecciones de datos de tipo no numérico, tales como 
las cadenas. 
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Como ejemplo, considérese la consulta «Obtener la 
media de saldos de las cuentas de la sucursal Navacerra- 
da». Esta consulta se puede formular del modo siguiente: 

select avg (saldo) 
from cuenta 

where nombre-sucursal = ‘Navacerrada’ 

El resultado de esta consulta será una relación con un úni¬ 
co atributo, que contendrá una única ñla con un valor 
numérico correspondiente al saldo medio de la sucursal 
Navacerrada. Opcionalmente se puede dar un nombre al 
atributo resultado de la relación, usando la cláusula as. 

Existen situaciones en las cuales sería deseable apli¬ 
car las funciones de agregación no sólo a un único con¬ 
junto de tupias sino también a un grupo de conjuntos de 
tupias; esto se especifica en SQL usando la cláusula 
group by. El atributo o atributos especificados en la 
cláusula group by se usan para formar grupos. Las tupias 
con el mismo valor en todos los atributos especificados 
en la cláusula group by se colocan en un grupo. 

Como ejemplo, considérese la consulta «Obtener el 
saldo medio de las cuentas de cada sucursal». 

Dicha consulta se formulará del modo siguiente 

select nombre-sucursal, avg (saldo) 
from cuenta 

group by nombre-sucursal 

La conservación de duplicados es importante al calcu¬ 
lar una media. Supóngase que los saldos de las cuentas 
en la (pequeña) sucursal de nombre «Galapagar» son 
1.000 €, 3.000 €, 2.000 € y 1.000 €. El saldo medio 
es 7.000/4 =1.750 €. Si se eliminasen duplicados se 
obtendría un resultado erróneo (6.000/3 = 2.000 €). 

Hay casos en los que se deben eliminar los duplica¬ 
dos antes de calcular una función de agregación. Para 
eliminar duplicados se utiliza la palabra clave distinct 
en la expresión de agregación. Como ejemplo considé¬ 
rese la consulta «Obtener el número de impositores de 
cada sucursal». En este caso un impositor sólo se debe 
contar una vez, sin tener en cuenta el número de cuen¬ 
tas que el impositor pueda tener. La consulta se formu¬ 
lará del modo siguiente: 

select nombre-sucursal, count (distinct nombre- 
cliente) 

from impositor, cuenta 

where impositor.número-cuenta = cuenta.número- 
cuenta 

group by nombre-sucursal 

A veces es más útil establecer una condición que se 
aplique a los grupos que una que se aplique a las tupias. 
Por ejemplo, podemos estar interesados sólo en aquellas 
sucursales donde el saldo medio de cuentas es superior a 
1.200 €. Esta condición no es aplicable a una única tupia; 
se aplica a cada grupo construido por la cláusula group 
by. Para expresar este tipo de consultas se utiliza la cláu¬ 


sula having de SQL. Los predicados de la cláusula having 
se aplican después de la formación de grupos, de modo 
que se pueden usar las funciones de agregación. Esta con¬ 
sulta se expresa en SQL del modo siguiente: 

select nombre-sucursal, avg (saldo) 
from cuenta 

group by nombre-sucursal 
having avg (saldo) > 1200 

A veces se desea tratar la relación entera como un 
único grupo. En casos de este tipo no se usa la cláusu¬ 
la group by. Considérese la consulta «Obtener el sal¬ 
do medio de todas las cuentas». Esta consulta se for¬ 
mulará del modo siguiente: 

select avg (saldo) 
from cuenta 

Con mucha frecuencia se usa la función de agrega¬ 
ción count para contar el número de tupias de una rela¬ 
ción. La notación para esta función en SQL es count 
(*). Así, para encontrar el número de tupias de la rela¬ 
ción cliente, se escribirá 

select count (*) 

from cliente 

SQL no permite el uso de distinct con count (*). Sí 
se permite, sin embargo, el uso de distinct con max y 
min, incluso cuando el resultado no cambia. Se puede 
usar la palabra clave all en lugar de distinct para espe¬ 
cificar la retención de duplicados, pero como all se espe¬ 
cifica de manera predeterminada, no es necesario incluir 
dicha cláusula. 

Si en una misma consulta aparece una cláusula whe¬ 
re y una cláusula having, se aplica primero el predica¬ 
do de la cláusula where. Las tupias que satisfagan el 
predicado de la cláusula where se colocan en grupos 
según la cláusula group by. La cláusula having, si exis¬ 
te, se aplica entonces a cada grupo; los grupos que no 
satisfagan el predicado de la cláusula having se elimi¬ 
nan. La cláusula select utiliza los grupos restantes para 
generar las tupias resultado de la consulta. 

Para ilustrar el uso de la cláusula where y la cláu¬ 
sula having dentro de la misma consulta considérese el 
ejemplo «Obtener el saldo medio de cada cliente que 
vive en Madrid y tiene como mínimo tres cuentas». 

select impositor.nombre-cliente, avg (saldo) 
from impositor, cuenta, cliente 
where impositor.número-cuenta 

= cuenta.número-cuenta and 
impositor.nombre-cliente 
= cliente.nombre-cliente and 
ciudad-cliente = ‘Madrid’ 
group by impositor.nombre-cliente 
having count (distinct impositor.número-cuenta) >= 3 
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4.5. VALORES NULOS 


SQL permite el uso de valores nulos para indicar la 
ausencia de información sobre el valor de un atributo. 

En un predicado se puede usar la palabra clave espe¬ 
cial nuil para comprobar si un valor es nulo. Así, para 
encontrar todos los números de préstamo que aparecen 
en la relación préstamo con valores nulos para impor¬ 
te se escribe 

select número-préstamo 
from préstamo 
where importe is nuil 

El predicado is not nuil pregunta por la ausencia de un 
valor nulo. 

El uso de un valor nulo en las operaciones aritméti¬ 
cas y de comparación causa varias complicaciones. En 
el Apartado 3.3.4 se vio cómo se manejan los valores 
nulos en el álgebra relacional. Ahora se describe cómo 
maneja SQL los valores nulos. 

El resultado de una expresión aritmética (incluyen¬ 
do por ejemplo o /) es nulo si cualquiera de los 
valores de entrada es nulo. SQL trata como desconoci¬ 
do el resultado de cualquier comparación que implique 
un valor nulo (aparte de is nuil e is not nuil). 

Dado que el predicado en una cláusula where pue¬ 
de incluir operaciones booleanas tales como and, or y 
not sobre los resultados de las comparaciones, las defi¬ 
niciones de estas operaciones se extienden para mane¬ 
jar el valor desconocido, como se describe en el Apar¬ 
tado 3.3.4. 

• and: el resultado de cierto and desconocido es des¬ 
conocido,falso and desconocido es falso, mientras 
que desconocido and desconocido es desconocido. 

• or: el resultado de cierto or desconocido es cier¬ 
to, falso or desconocido es desconocido, mientras 
que desconocido or desconocido es desconocido. 

SQL define el resultado de una instrucción SQL de la 
forma 

select... from R lt ..... R n where P 


para contener (proyecciones de) tupias en R t x ... x R n 
para las que el predicado P se evalúa a cierto. Si el pre¬ 
dicado se evalúa a falso o desconocido para una tupia 
de R¡ x ... x R„ (la proyección de) la tupia no se añade 
al resultado. 

SQL también permite determinar si el resultado de 
una comparación es desconocido en lugar de cierto o 
falso usando las cláusulas is unknown (es desconoci¬ 
do) e is not unknown (no es desconocido) 

La existencia de valores nulos también complica el 
procesamiento de los operadores de agregación. Supón¬ 
gase que algunas tupias en la relación préstamo tienen 
valor nulo para el atributo importe. Considérese en ese 
caso la siguiente consulta, que calcula el total de todas 
las cantidades prestadas: 

select sum ( importe) 
from préstamo 

Los valores que van a ser sumados en la consulta ante¬ 
rior incluyen valores nulos, puesto que algunas tupias 
tienen valor nulo para el atributo importe. En lugar de 
decir que la suma total es nula, la norma SQL estable¬ 
ce que el operador sum debería ignorar los valores nulos 
de su entrada. 

En general, las funciones de agregación tratan los 
valores nulos según la regla siguiente: todas las funcio¬ 
nes de agregación excepto count(*) ignoran los valores 
nulos de la colección de datos de entrada. Como resul¬ 
tado de ignorar los valores nulos, la colección de valo¬ 
res de entrada puede resultar vacía. El cálculo de count 
de una colección vacía se define como 0 y todas las demás 
operaciones de agregación devuelven un valor nulo cuan¬ 
do se aplican sobre una colección de datos vacía. El efec¬ 
to de los valores nulos en algunas de las construcciones 
más complicadas de SQL puede ser más sutil. 

En SQL: 1999 se introdujo un tipo de datos boolean, 
que puede tomar los valores cierto, falso y desconoci¬ 
do. Las funciones de agregación some (algún) y every 
(cada), que significan exactamente lo que se espera de 
ellas, se pueden aplicar a una colección de valores boo- 
leanos. 


4.6. SUBCONSULTAS ANIDADAS 


SQL proporciona un mecanismo para las subconsultas 
anidadas. Una subconsulta es una expresión select-from- 
where que se anida dentro de otra consulta. Un uso 
común de subconsultas es llevar a cabo comprobacio¬ 
nes sobre pertenencia a conjuntos, comparación de con¬ 
juntos y cardinalidad de conjuntos. Estos usos se estu¬ 
diarán en los apartados siguientes. 


4.6.1. Pertenencia a conjuntos 

SQL utiliza el cálculo relacional para las operaciones 
que permiten comprobar la pertenencia de una tupia a 
una relación. La conectiva in comprueba la pertenen¬ 
cia a un conjunto, donde el conjunto es la colección de 
valores resultado de una cláusula select. La conectiva 
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not in comprueba la no pertenencia a un conjunto. 
Como ejemplo considérese de nuevo la consulta 
«Encontrar todos los clientes que tienen tanto un prés¬ 
tamo como una cuenta en el banco». Anteriormente 
escribimos esta consulta como la intersección de dos 
conjuntos: el conjunto de los impositores del banco y 
el conjunto de los prestatarios del banco. Sin embargo, 
existe un enfoque alternativo consistente en encontrar 
todos los tenedores de cuentas en el banco que son 
miembros del conjunto de prestatarios. Claramente, 
esta formulación genera el mismo resultado que la ante¬ 
rior, pero obliga a formular la consulta usando la conec¬ 
tiva in de SQL. A continuación, se van a obtener todos 
los tenedores de cuentas formulando así la siguiente 
subconsulta: 

(select nombre-cliente 
from impositor) 

A continuación es necesario encontrar aquellos clientes 
que son prestatarios del banco y que aparecen en la lis¬ 
ta de tenedores de cuenta, obtenida como resultado de 
la subconsulta anterior. Esto se consigue anidando la 
subconsulta en un select más extemo. La consulta resul¬ 
tante es la siguiente: 

select distinct nombre-cliente 
from prestatario 

where nombre-cliente in (select nombre-cliente 
from impositor) 

Este ejemplo muestra que es posible escribir la mis¬ 
ma consulta de diversas formas en SQL. Esta flexibili¬ 
dad es de gran utilidad, puesto que permite al usuario 
pensar en una consulta del modo que le parezca más 
natural. Más adelante se verá que existe una gran can¬ 
tidad de redundancia en SQL. 

En el ejemplo anterior se comprobaba la pertenen¬ 
cia a un conjunto en una relación de un solo atributo. 
También es posible comprobar la pertenencia a un con¬ 
junto en una relación cualquiera. Así, se puede formu¬ 
lar la consulta «Listar los clientes que tienen tanto una 
cuenta como un préstamo en la sucursal Navacerrada» 
de un modo distinto al visto anteriormente: 

select distinct nombre-cliente 
from prestatario, préstamo 
where prestatario.número-préstamo = 
préstamo.número-préstamo and 
nombre-sucursal = ‘Navacerrada’ and 
{nombre-sucursal, nombre-cliente) in 
(select nombre-sucursal, nombre-cliente 
from impositor, cuenta 
where impositor.número-cuenta 
= cuenta, número-cuenta) 

A continuación, se ilustra el uso de la constructora 
not in. Por ejemplo, para encontrar todos los clientes 


que tienen un préstamo en el banco, pero no tienen una 
cuenta en el banco, se puede escribir 

select distinct nombre-cliente 
from prestatario 

where nombre-cliente not in (select nombre-cliente 

from impositor) 

Los operadores in y not in también se pueden usar 
sobre conjuntos enumerados. La consulta siguiente 
selecciona los nombres de los clientes que tienen un 
préstamo en el banco y cuyos nombres no son ni «San¬ 
tos» ni «Gómez». 

select distinct nombre-cliente 
from prestatario 

where nombre-cliente not in (‘Santos’, ‘Gómez’) 

4.6.2. Comparación de conjuntos 

Considérese la consulta «Obtener los nombres de todas 
las sucursales que poseen un activo mayor que al menos 
una sucursal situada en Barcelona». En el Apartado 4.2.5 
se formulaba esta consulta del modo siguiente: 

select distinct T.nombre-sucursal 
from sucursal as T, sucursal as S 
where T.activo > S.activo and 

S.ciudad-sucursal = ‘Barcelona’ 

SQL ofrece, sin embargo, un estilo alternativo de for¬ 
mular la consulta anterior. La expresión: «mayor que al 
menos una» se representa en SQL por > some. Esta 
constructora permite reescribir la consulta en una for¬ 
ma más parecida a la formulación de la consulta en len¬ 
guaje natural. 

select nombre-sucursal 
from sucursal 

where activo > some (select activo 
from sucursal 
where ciudad-sucursal 
= ‘Barcelona’) 

La subconsulta 

(select activo 
from sucursal 

where ciudad-sucursal = ‘Barcelona’) 

genera el conjunto de todos los valores de activo para 
todas las sucursales sitas en Barcelona. La comparación 
> some, en la cláusula where de la cláusula select más 
externa, es cierta si el valor del atributo activo de la tupia 
es mayor que al menos un miembro del conjunto de todos 
los valores de activo de las sucursales de Barcelona. 

SQL también permite realizar las comparaciones < 
some, <= some, >= some, = some y o some. Como ejer- 
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cicio, se puede verificar que = some es idéntico a in, mien¬ 
tras que <= some no es lo mismo que not in. En SQL, la 
palabra clave any es sinónimo de some. Las versiones 
más antiguas de SQL sólo admitían any. Sin embargo, 
versiones posteriores añadieron la alternativa some para 
evitar la ambigüedad lingüística de la palabra inglesa any. 

Ahora la consulta se modificará ligeramente a fin de 
obtener los nombres de todas las sucursales que tienen 
un activo superior al de todas las sucursales de Barce¬ 
lona. La constructora > all corresponde a la expresión 
«superior a todas». Utilizando esta constructora la con¬ 
sulta se podría formular del modo siguiente: 

select nombre-sucursal 
from sucursal 

where activo > all (select activo 
from sucursal 
where ciudad-sucursal 
= ‘Barcelona’) 

Al igual que con some, SQL también permite utilizar 
las comparaciones < all, <= all, >= all, = all y o all. 
Como ejercicio se puede verificar que <= any es lo mis¬ 
mo que not in. 

Como otro ejemplo de comparaciones considérese 
la consulta «Encontrar la sucursal que tiene el mayor 
saldo medio». En SQL, las funciones de agregación no 
se pueden componer. Así, no está permitido el uso de 
max (avg (...)). Por ello, para la formulación de esta 
consulta se seguirá la estrategia siguiente: para empe¬ 
zar se formula una consulta para encontrar todos los sal¬ 
dos medios, y luego se anida ésta como subconsulta de 
una consulta más larga que encuentre aquellas sucur¬ 
sales para las que el saldo medio es mayor o igual que 
todos los saldos medios: 

select nombre-sucursal 
from cuenta 

group by nombre-sucursal 

having avg (saldo) >= all (select avg (saldo) 

from cuenta 

group by nombre-sucursal) 

4.6.3. Comprobación de relaciones vacías 

SQL incluye la posibilidad de comprobar si una sub¬ 
consulta no produce ninguna tupia como resultado. La 
constructora exists devuelve el valor cierto si la sub¬ 
consulta argumento no es vacía. 

Usando la constructora exists se puede formular la 
consulta «Obtener los clientes que tienen tanto una cuen¬ 
ta como un préstamo en el banco» de otra nueva forma: 

select nombre-cliente 

where exists (select * 

from impositor 

where impositor.nombre-cliente = 
prestatario.nombre-cliente) 


Utilizando la constructora not exists se puede com¬ 
probar la inexistencia de tupias en el resultado de una 
subconsulta. Además, es posible usar la constructora 
not exists para simular la operación de continencia de 
conjuntos (es decir, superconjunto). Así, se puede escri¬ 
bir la expresión «la relación A contiene a la relación B» 
como «not exists (B except A)». Aunque no forma par¬ 
te de SQL estándar, el operador contains aparece en 
algunos sistemas relaciónales. Para ilustrar el operador 
not exists considérese otra vez la consulta «Obtener 
todos los clientes que tienen una cuenta en todas las 
sucursales de Barcelona». Será necesario comprobar 
para cada cliente si el conjunto de todas las sucursales 
en las que dicho cliente tiene cuenta contiene al con¬ 
junto de todas las sucursales de Barcelona. Utilizando 
el operador except se puede formular la consulta del 
modo siguiente: 

select distinct S.nombre-cliente 
from impositor as S 

where not exists ((select nombre-sucursal 
from sucursal 
where ciudad-sucursal 
= ‘Barcelona’) 

except 

(select R.nombre-sucursal 
from impositor as T, cuenta as R 
where T.número-cuenta 

= R.número-cuenta and 
S. nombre-cliente 
= T.nombre-cliente)) 

En este ejemplo, la subconsulta 

(select nombre-sucursal 
from sucursal 

where ciudad-sucursal = ‘Barcelona’) 

obtiene todas las sucursales de Barcelona. Por otro lado, 
la subconsulta 

(select R.nombre-sucursal 
from impositor as T, cuenta as R 
where T.número-cuenta = R.número-cuenta and 
S.nombre-cliente = T.nombre-cliente ) 

obtiene todas las sucursales en las cuales el cliente 
S.nombre-cliente tiene una cuenta. Por último, el select 
más externo toma cada cliente y comprueba si el con¬ 
junto de todas las sucursales en las que dicho cliente 
tiene cuenta, contiene al conjunto de todas las sucursa¬ 
les de Barcelona. 

En consultas que contengan subconsultas se aplica 
una regla de visibilidad para las variables tupia. En una 
subconsulta, sólo se pueden usar variables tupia que 
estén definidas en la propia subconsulta o en cualquier 
consulta que contenga a dicha subconsulta. Si una varia¬ 
ble tupia está definida tanto localmente (en una sub- 
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consulta) como globalmente (en una consulta que con¬ 
tenga a la subconsulta) se aplica la definición local. Esta 
regla es análoga a la utilizada para las variables en los 
lenguajes de programación. 

4.6.4. Comprobación de tupias duplicadas 

SQL incluye la posibilidad de comprobar si una sub¬ 
consulta produce como resultado tupias duplicadas. La 
constructora unique devuelve el valor cierto si la sub¬ 
consulta que se le pasa como argumento no produce 
tupias duplicadas. Usando la constructora unique se 
puede formular la consulta «Obtener todos los clientes 
que tienen sólo una cuenta en la sucursal de nombre 
Navacerrada» del siguiente modo: 

select T.nombre-cliente 

from impositor as T 

where unique (select R.nombre-cliente 

from cuenta, impositor as R 
where T.nombre-cliente 

= R.nombre-cliente and 
R. número-cuenta 
= cuenta.número-cuenta and 
cuenta.nombre-sucursal 
= ‘Navacerrada’) 


La existencia de tupias duplicadas en una subconsulta 
se puede comprobar utilizando la constructora not uni¬ 
que. Para ilustrar esta constructora considérese la con¬ 
sulta «Obtener todos los clientes que tienen al menos 
dos cuentas en la sucursal Navacerrada», que se puede 
formular del modo siguiente: 

select distinct T.nombre-cliente 
from impositor as T 

where not unique (select R.nombre-cliente 

from cuenta, impositor as R 
where T.nombre-cliente 

= R.nombre-cliente and 
R. número-cuenta = 
cuenta.número-cuenta and 
cuenta.número-sucursal 
= ‘Navacerrada’) 

Lormalmente, la comprobación hecha por la cons¬ 
tructora unique sobre una relación debería fallar si y 
sólo si en la relación existieran dos tupias t l y t 2 tales 
que q = t 2 . Como la comprobación t { = t 2 sólo falla si 
cualquier campo de t l o de t 2 es nulo, entonces es posi¬ 
ble que el resultado de unique sea cierto incluso si exis¬ 
ten varias copias de una tupia, siempre que al menos 
uno de los atributos de la tupia sea nulo. 


4.7. VISTAS 


Una vista en SQL se define utilizando la orden create 
view. Para definir una vista se le debe dar un nombre y 
se debe construir la consulta que genere dicha vista. La 
forma de la orden create view es la siguiente: 

create view v as <expresión de consulta> 

donde <expresión de consulta> puede ser cualquier con¬ 
sulta válida. El nombre de la vista se representa por v. 
Nótese que la notación usada para la definición de una 
vista en el álgebra relacional (véase Capítulo 3) se basa 
en esta de SQL. 

Como ejemplo considérese la vista consistente en los 
nombres de sucursales y los nombres de los clientes que 
tienen una cuenta o un préstamo en esa sucursal. Si se 
denomina esta vista como todos-los-clientes se defini¬ 
rá del modo siguiente: 

create view todos-los-clientes as 

(select nombre-sucursal, nombre-cliente 
from impositor, cuenta 
where impositor.número-cuenta 
= cuenta.número-cuenta) 

unión 

(select nombre-sucursal, nombre-cliente 
from prestatario, préstamo 


where prestatario.número-préstamo 
= préstamo.número-préstamo) 

Los nombres de los atributos de una vista se pueden 
indicar explícitamente de la forma siguiente: 

create view total-préstamos-sucursal 

(nombre-sucursal, total-préstamos) as 
select nombre-sucursal, sum ( importe) 
from préstamo 
group by nombre-sucursal 

La vista anterior contiene para cada sucursal la suma de 
los importes de todos los préstamos de esa sucursal. 
Como la expresión sum ( importe) no tiene nombre, el 
nombre del atributo se especifica explícitamente en la 
definición de la vista. 

Los nombres de vistas pueden aparecer en cual¬ 
quier lugar en el que pudiera aparecer un nombre de 
relación. Usando la vista todos-los-clientes, se pue¬ 
den listar todos los clientes de la sucursal Navacerra¬ 
da, escribiendo 

select nombre-cliente 

from todos-los-clientes 

where nombre-sucursal = ‘Navacerrada’ 
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4.8. CONSULTAS COMPLEJAS 


Las consultas complejas son a menudo difíciles o 
imposibles de escribir como un único bloque SQL o 
una unión, intersección o diferencia de bloques SQL 
(un bloque SQL consiste en una única instrucción 
select from where, posiblemente con cláusulas group 
by y having). Aquí se estudian dos formas de com¬ 
poner varios bloques SQL para expresar una consul¬ 
ta compleja: las relaciones derivadas y la cláusula 
with. 

4.8.1. Relaciones derivadas 

SQL permite el uso de una expresión de subconsulta en 
la cláusula from. Si se usa una expresión de este tipo 
se debe dar un nombre a la relación resultado y se pue¬ 
den renombrar los atributos usando la cláusula as. Por 
ejemplo, considérese la subconsulta 

(select nombre-sucursal, avg (saldo) 

from cuenta 

group by nombre-sucursal) 
as media-sucursal (nombre-sucursal, saldo-meclio) 

Esta subconsulta produce una relación consistente en 
los nombres de todas las sucursales y sus correspon¬ 
dientes saldos de cuenta medios. El resultado de la sub¬ 
consulta recibe el nombre de media-sucursal y contie¬ 
ne los atributos nombre-sucursal y saldo-medio. 

Para ilustrar el uso de una expresión de subconsul¬ 
ta en la cláusula from considérese la consulta «Obte¬ 
ner el saldo medio de las cuentas de aquellas sucursa¬ 
les donde dicho saldo medio sea superior a 1.200 €». 
En el Apartado 4.4 se formulaba esta consulta utili¬ 
zando la cláusula having. Ahora se puede reescribir 
dicha consulta sin usar esta cláusula de la siguiente 
forma: 

select nombre-sucursal, saldo-medio 
from (select nombre-sucursal, avg (saldo) 
from cuenta 

group by nombre-sucursal) 
as resultado ( nombre-sucursal, saldo-medio) 
where saldo-medio > 1200 

En esta formulación no es necesario el uso de la cláu¬ 
sula having puesto que la relación temporal resulta¬ 
do se calcula en la cláusula from, y los atributos de 
resultado se pueden usar directamente en la cláusula 

where. 

Supóngase como otro ejemplo que se desea hallar 
el máximo del total de saldos de todas las sucursales. 
La cláusula having no sirve en este caso, pero se pue¬ 
de escribir fácilmente esta consulta usando una sub¬ 
consulta en la cláusula from, como se muestra a conti¬ 
nuación: 


select ma \(saldo-total) 
from (select nombre-sucursal, sum (saldo) 
from cuenta 

group by nombre-sucursal) as 

total-sucursal(nombre-sucursal, 

saldo-total) 

4.8.2. La cláusula with 

Las consultas complicadas son mucho más fáciles de 
formular y de entender si se descomponen en vistas 
más simples y después se combinan, al igual que se 
estructuran los programas, descomponiendo sus tareas 
en procedimientos. Sin embargo, son distintas a la defi¬ 
nición de procedimientos en cuanto a que una cláusu¬ 
la create view crea una definición de vista en la base 
de datos y esa definición de vista permanece en la base 
de datos hasta que se ejecuta una orden drop view nom¬ 
bre-vista. 

La cláusula with proporciona una forma de definir 
una vista temporal cuya definición está disponible sólo 
para la consulta en la que aparece esta cláusula. Consi¬ 
dérese la siguiente consulta, que selecciona cuentas con 
el saldo máximo; si hay muchas cuentas con el mismo 
saldo máximo, todas ellas se seleccionan. 

with saldo-máximo(valor) as 
select max (saldo) 
from cuenta 
select número-cuenta 
from cuenta, saldo-máximo 
where cuenta.saldo = saldo-máximo.valor 

La cláusula with introducida en SQL: 1999 se incluye 
actualmente sólo en algunas bases de datos. 

Se podría haber escrito la consulta anterior usando 
una subconsulta anidada tanto en la cláusula from como 
en la where. Sin embargo, el uso de subconsultas ani¬ 
dadas hace que la consulta sea más difícil de leer y 
entender. La cláusula with hace que la lógica de la con¬ 
sulta sea más clara; también permite usar una definición 
de vista en varios lugares de una consulta. 

Por ejemplo, supóngase que se desea encontrar todas 
las sucursales donde el depósito de cuentas es mayor 
que la media del total de depósitos de cuentas en todas 
las sucursales. Se puede escribir la consulta con la cláu¬ 
sula with como se muestra a continuación. 

with total-sucursal(nombre-sucursal,valor) as 
select nombre-sucursal, sum (saldo) 
from cuenta 

group by nombre-sucursal 
with total-media-sucursal(valor) as 
select avgQa valor Ido) 
from total-sucursal 
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select nombre-sucursal 
from total-sucursal, total-media-sucursal 
where total-sucursal.valor > = total-media- 
sucursal.valor 


Por supuesto, se puede crear una consulta equivalente 
sin la cláusula with, pero sería más complicada y difí¬ 
cil de entender. Como ejercicio, se puede escribir la con¬ 
sulta equivalente. 


4.9. MODIFICACIÓN DE LA BASE DE DATOS 


Hasta ahora nos hemos limitado a la extracción de infor¬ 
mación de una base de datos. A continuación se mos¬ 
trará cómo añadir, eliminar o cambiar información uti¬ 
lizando SQL. 

4.9.1. Borrado 

Un borrado se expresa de igual modo que una consul¬ 
ta. Se pueden borrar sólo tupias completas, es decir, no 
se pueden borrar valores de atributos concretos. Un 
borrado se expresa en SQL del modo siguiente: 

delete from r 
where P 

donde P representa un predicado y r representa una rela¬ 
ción. La declaración delete selecciona primero todas 
las tupias t en r para las que P (t) es cierto y a conti¬ 
nuación las borra de r. La cláusula where se puede omi¬ 
tir, en cuyo caso se borran todas las tupias de r. 

Hay que señalar que una orden delete opera sólo 
sobre una relación. Si se desea borrar tupias de varias 
relaciones, se deberá utilizar una orden delete por cada 
relación. El predicado de la cláusula where puede ser 
tan complicado como el where de cualquier cláusula 
select, o tan simple como una cláusula where vacía. La 
consulta 

delete from préstamo 

borra todas las tupias de la relación préstamo (los sis¬ 
temas bien diseñados requerirán una confirmación del 
usuario antes de ejecutar una consulta tan devastadora). 

A continuación se muestran una serie de ejemplos 
de borrados en SQL. 

• Borrar todas las cuentas de la sucursal Navacerrada. 

delete from cuenta 

where nombre-sucursal = ‘Navacerrada’ 

• Borrar todos los préstamos en los que la cantidad esté 
comprendida entre 1.300 € y 1.500 €. 

delete from préstamo 

where importe between 1300 and 1500 

• Borrar las cuentas de todas las sucursales de Nava- 
cerrada. 


delete from cuenta 

where nombre-sucursal in (select nombre-sucursal 

from sucursal 
where ciudad-sucursal 
= ‘Navacerrada’) 

El borrado anterior selecciona primero todas las sucur¬ 
sales con sede en Navacerrada y a continuación borra 
todas las tupias cuenta pertenecientes a esas sucursa¬ 
les. 

Nótese que, si bien sólo se pueden borrar tupias de 
una sola relación cada vez, se puede utilizar cualquier 
número de relaciones en una expresión select-from- 
where anidada en la cláusula where de un delete. La 
orden delete puede contener un select anidado que use 
una relación de la cual se van a borrar tupias. Por ejem¬ 
plo, para borrar todas las cuentas cuyos saldos sean infe¬ 
riores a la media del banco se puede escribir: 

delete from cuenta 
where saldo < (select avg (saldo) 
from cuenta) 

La orden delete comprueba primero cada tupia de la 
relación cuenta para comprobar si la cuenta tiene un sal¬ 
do inferior a la media del banco. A continuación se 
borran todas las tupias que no cumplan la condición 
anterior, es decir, las que representan una cuenta con un 
saldo menor que la media. Es importante realizar todas 
las comprobaciones antes de llevar a cabo ningún borra¬ 
do (si se borrasen algunas tupias antes de que otras fue¬ 
ran comprobadas, el saldo medio podría haber cambia¬ 
do y el resultado final del borrado dependería del orden 
en que las tupias fueran procesadas). 

4.9.2. Inserción 

Para insertar datos en una relación, o bien se especifica 
la tupia que se desea insertar o se formula una consul¬ 
ta cuyo resultado sea el conjunto de tupias que se de¬ 
sean insertar. Obviamente, los valores de los atributos 
de la tupias que se inserten deben pertenecer al domi¬ 
nio de los atributos. De igual modo, las tupias inserta¬ 
das deberán ser de la aridad correcta. 

La instrucción ¡nsert más sencilla corresponde a la 
de inserción de una tupia. Supongamos que se desea 
insertar en la base de datos el hecho de que hay una 
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cuenta C-9732 en la sucursal Navacerrada y que dicha 
cuenta tiene un saldo de 1.200 €. La inserción se pue¬ 
de formular del modo siguiente: 

¡nsert into cuenta 

valúes (‘C-9732’, ‘Navacerrada’, 1200) 

En este ejemplo los valores se especifican en el mismo 
orden en que los atributos se listan en el esquema de 
relación. Para beneficio de los usuarios, que pueden no 
recordar el orden de los atributos, SQL permite que los 
atributos se especifiquen en la cláusula insert. Así, el 
siguiente ejemplo tiene una función idéntica al anterior: 

insert into cuenta ( nombre-sucursal, número- 
cuenta, saldo) 

valúes (‘Navacerrada’, ‘C-9732’, 1200) 

insert into cuenta ( número-cuenta, nombre- 
sucursal, saldo) 

valúes (‘C-9732’, ‘Navacerrada’, 1200) 

Generalmente se desea insertar las tupias que resul¬ 
tan de una consulta. Por ejemplo, si a todos los clientes 
tenedores de préstamos en la sucursal Navacerrada se 
les quisiera regalar, como gratificación, una cuenta de 
ahorro con 200 € por cada cuenta de préstamo que tie¬ 
nen, se podría escribir: 

insert into cuenta 

select nombre-sucursal, número-préstamo, 200 
from préstamo 

where nombre-sucursal = ‘Navacerrada’ 

En lugar de especificar una tupia, como se hizo en los 
primeros ejemplos de este apartado, se utiliza una ins¬ 
trucción select para especificar un conjunto de tupias. 
La instrucción select se evalúa primero, produciendo 
un conjunto de tupias que a continuación se insertan en 
la relación cuenta. Cada tupia tiene un nombre-sucur¬ 
sal (Navacerrada), un número-préstamo (que sirve como 
número de cuenta para la nueva cuenta) y un saldo ini¬ 
cial de la cuenta (200 €). 

Además es necesario añadir tupias a la relación impo- 
sitor, para hacer esto, se escribirá: 

insert into impositor 

select nombre-cliente, número-préstamo 

from prestatario, préstamo 

where prestatario.número-préstamo 

= préstamo.número-préstamo and 
nombre-sucursal = ‘Navacerrada’ 

Esta consulta inserta en la relación impositor una 
tupia ( nombre-cliente, número-préstamo) por cada 
nombre-cliente que posea un préstamo en la sucursal 
Navacerrada, con número de préstamo número-prés¬ 
tamo. 


Es importante que la evaluación de la instrucción 
select finalice completamente antes de llevar a cabo nin¬ 
guna inserción. Si se realizase alguna inserción antes 
de que finalizase la evaluación de la instrucción select, 
una consulta del tipo: 

insert into cuenta 
select * 

from cuenta 

podría insertar un número infinito de tupias. La prime¬ 
ra tupia de la relación cuenta se insertaría de nuevo en 
cuenta, creando así una segunda copia de la tupia. Como 
esta segunda copia ya sería parte de cuenta, la instruc¬ 
ción select podría seleccionarla, insertando así una ter¬ 
cera copia en la relación cuenta. Esta tercera copia 
podría ser seleccionada a continuación por el select e 
insertar una cuarta copia y así infinitamente. Evaluan¬ 
do completamente toda la instrucción select antes de 
realizar ninguna inserción se evitan este tipo de pro¬ 
blemas. 

Por ahora, en el estudio de la instrucción insert sólo 
se han considerado ejemplos en los que se especificaba 
un valor para cada atributo de las tupias insertadas. 
Como se estudió en el Capítulo 3, es posible indicar sólo 
valores para algunos de los atributos del esquema. 
A cada uno de los atributos restantes, se les asignará un 
valor nulo, que se denota por nuil. Como ejemplo con¬ 
sidérese la consulta: 

¡nsert Into cuenta 

valúes (‘C-401’, nuil, 1200) 

en la que se sabe que la cuenta C-401 tiene un saldo de 
1.200 €, pero no se conoce el nombre de la sucursal. 
Considérese ahora la consulta 

select número-cuenta 
from cuenta 

where nombre-sucursal = ‘Navacerrada’ 

Como el nombre de la sucursal de la cuenta C-401 es 
desconocido, no se puede determinar si es igual a «Nava- 
cerrada». 

Se puede prohibir la inserción de valores nulos utili¬ 
zando el LDD de SQL, que se estudia en el Apartado 4.11. 

4.9.3. Actualizaciones 

En determinadas situaciones puede ser deseable cam¬ 
biar un valor dentro de una tupia, sin cambiar todos los 
valores de la misma. Para este tipo de situaciones se uti¬ 
liza la instrucción update. Al igual que ocurre con ¡nsert 
y delete, se pueden elegir las tupias que van a ser actua¬ 
lizadas mediante una consulta. 

Por ejemplo, si hubiera que realizar el pago de inte¬ 
reses anuales y todos los saldos se incrementasen en un 
5 %, habría que formular la siguiente actualización: 
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update cuenta 

set saldo = saldo * 1.05 

Esta actualización se aplica una vez a cada tupia de la 
relación cuenta. 

Si se paga el interés sólo a las cuentas con un saldo 
de 1.000 € o superior, se puede escribir 

update cuenta 

set saldo = saldo * 1.05 

where saldo >= 1000 

En general, la cláusula where de la instrucción upda¬ 
te puede contener cualquier constructor legar en la cláu¬ 
sula where de una instrucción select (incluyendo ins¬ 
trucciones select anidadas). Como con inserí y delete, 
un select anidado en una instrucción update puede refe- 
renciar la relación que se esté actualizando. Como antes, 
SQL primero comprueba todas las tupias de la relación 
para determinar las que se deberían actualizar y después 
realiza la actualización. Por ejemplo, se puede escribir 
«Pagar un interés del 5% a las cuentas cuyo saldo sea 
mayor que la media» como sigue: 

update cuenta 
set saldo = saldo * 1.05 
where ( saldo > select avg (saldo) 
from cuenta ) 

Si se supone que las cuentas con saldos superiores a 
10.000 € reciben un 6% de interés, mientras que las 
demás un 5%, se deberán escribir dos instrucciones de 
actualización: 

update cuenta 

set saldo = saldo * 1.06 

where saldo > 10000 

update cuenta 

set saldo = saldo * 1.05 

where saldo <= 10000 

Obsérvese que, como se vio en el Capítulo 3, el orden 
en el que se ejecutan dos instrucciones de actualización 
es importante. Si se invierte el orden de las dos ins¬ 
trucciones anteriores, una cuenta con un saldo igual o 
muy poco inferior a 10.000 € recibiría un 11,3% de 
interés. 

SQL ofrece una constructora case, que se puede usar 
para formular las dos instrucciones de actualización 
anteriores en una única instrucción de actualización, 
evitando el problema del orden de actualización. 

update cuenta 
set saldo = case 

when saldo <= 10000 then saldo * 1.05 
else saldo * 1.06 

end 


La forma general de la instrucción case es la siguien¬ 
te: 

case 

when pred t then resulta 
when pred 2 then result 2 

when pred n then result n 
else result 0 

end 

La operación devuelve resulta donde i es el primero de 
result { , result 2 ,. ..,result n que se satisface; si ninguno de 
ellos se satisface, la operación devuelve result 0 . Las ins¬ 
trucciones case se pueden usar en cualquier lugar don¬ 
de se espere un valor. 

4.9.4. Actualización de vistas 

La anomalía de la actualización de vistas estudiada en 
el Capítulo 3 también se produce en SQL. Como ejem¬ 
plo considérese la siguiente definición de vista: 

create view préstamo-sucursal as 

select nombre-sucursal, número-préstamo 
from préstamo 

Como SQL permite que el nombre de una vista aparez¬ 
ca en cualquier lugar en el que pueda aparecer el nom¬ 
bre de una relación, se puede formular: 

insert into préstamo-sucursal 

valúes (‘Navacerrada’, ‘P-307’) 

SQL representa esta inserción mediante una inserción 
en la relación préstamo, puesto que préstamo es la rela¬ 
ción real a partir de la cual se construye la vista prés¬ 
tamo-sucursal. Por lo tanto, debería especificarse un 
valor para el atributo importe. Este valor es un valor 
nulo. De este modo, la inserción anterior es equivalen¬ 
te a la inserción de la tupia 

(‘P-307’, ‘Navacerrada’, nuil) 

en la relación préstamo. 

Como vimos en el Capítulo 3, la anomalía de la 
actualización de vistas se agrava cuando una vista se 
define en términos de varias relaciones. Como resultado, 
muchas bases de datos basadas en SQL imponen la siguien¬ 
te restricción a las modificaciones de vistas: 

• Una modificación de una vista es válida sólo si la 
vista en cuestión se define en términos de la base 
de datos relacional real, esto es, del nivel lógico 
de la base de datos (y sin usar agregación). 

Bajo esta restricción, las operaciones update, insert y 
delete realizadas sobre el ejemplo de la vista todos-los- 
clientes definida anteriormente, estarían prohibidas. 
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4.9.5. Transacciones 

Una transacción consiste en una secuencia de instruc¬ 
ciones de consulta y actualizaciones. La norma SQL espe¬ 
cifica que una transacción comienza implícitamente cuan¬ 
do se ejecuta una instrucción SQL. Una de las siguientes 
instrucciones SQL debe finalizar la transacción: 

• Commit work compromete la transacción actual; 
es decir, hace que los cambios realizados por la 
transacción sean permanentes en la base de datos. 
Después de que se comprometa la transacción se 
inicia una nueva transacción automáticamente. 

• Rollback work causa el retroceso de la transac¬ 
ción actual; es decir, deshace todas las actualiza¬ 
ciones realizadas por las instrucciones SQL de la 
transacción; así, el estado de la base de datos se 
restaura al que existía previo a la ejecución de la 
transacción. 

La palabra work es opcional en ambas instrucciones. 

El retroceso de transacciones es útil si se detecta algu¬ 
na condición de error durante la ejecución de una tran¬ 
sacción. El compromiso es similar, bajo un punto de 
vista, a guardar los cambios de un documento que se 
esté modificando, mientras que el retroceso es similar 
a abandonar la sesión de modificación sin guardar los 
cambios. Una vez que una transacción haya ejecutado 
commit work, sus efectos no se pueden deshacer con 
rollback work. El sistema de bases de datos garantiza 
que en el caso de una caída, los efectos de la transac¬ 


ción se retrocederán si no se hubo ejecutado commit 
work. En el caso de fallo de alimentación o caída del 
sistema, el retroceso ocurre cuando el sistema se reini¬ 
cia. 

Por ejemplo, para transferir dinero de una cuenta a 
otra es necesario actualizar dos saldos de cuenta. Las 
dos instrucciones de actualización formarían una tran¬ 
sacción. Un error durante la ejecución de una de las ins¬ 
trucciones de una transacción resultaría en deshacer los 
efectos de las instrucciones anteriores de la transacción, 
de manera que la base de datos no se quedase en un esta¬ 
do parcialmente actualizado. En el Capítulo 15 se estu¬ 
dian más propiedades de las transacciones. 

Si un programa termina sin ejecutar ninguna de estas 
órdenes, las actualizaciones se comprometen o retroce¬ 
den. La norma no especifica cuál de los dos se debe rea¬ 
lizar, con lo que la elección es dependiente de la imple- 
mentación. En muchas implementaciones SQL, cada 
instrucción SQL es de manera predeterminada una tran¬ 
sacción y se compromete tan pronto como se ejecuta. 
El compromiso automático de las instrucciones SQL 
individuales se puede desactivar si es necesario ejecu¬ 
tar una transacción que conste de varias instrucciones 
SQL. La forma de desactivación del compromiso auto¬ 
mático depende de la implementación SQL específica. 

Una alternativa mejor, que es parte de la norma 
SQL: 1999 (pero actualmente sólo soportada por algu¬ 
nas implementaciones SQL), es permitir encerrar varias 
instrucciones SQL entre las palabras clave begin ato- 
mic ... end. Todas las instrucciones entre las palabras 
clave forman así una única transacción. 


4.10. REUNIÓN DE RELACIONES** 


Además de proporcionar el mecanismo básico de pro¬ 
ducto cartesiano para reunir tupias de relaciones, per¬ 
mitido en versiones anteriores, SQL también propor¬ 
ciona varios mecanismos para reunir relaciones, 
incluyendo reuniones condicionales y reuniones natu¬ 
rales, así como varias formas de reunión extema. Estas 
operaciones adicionales se usan a menudo como sub¬ 
consultas dentro de la cláusula from. 

4.10.1. Ejemplos 

En la Ligura 4.1 se muestran las relaciones présta¬ 
mo y prestatario que usarán las distintas operaciones 


de reunión que ilustraremos. Comenzaremos con un 
ejemplo simple de reunión interna. En la Ligura 4.2 se 
muestra el resultado de la expresión: 

préstamo inner join prestatario on 
préstamo.número-préstamo 
= prestatario.número-préstamo 

La expresión calcula la reunión zeta de las relaciones 
préstamo y prestatario , donde la condición de reunión 
es préstamo.número-préstamo = prestatario.número- 
préstamo. Los atributos del resultado son los atributos 
del lado izquierdo de la relación, seguidos por los del 
lado derecho de la misma. 


nombre-cliente 

número-préstamo 

Santos 

P-170 

Gómez 

P-230 

López 

P-155 


número-préstamo 

nombre-sucursal 

importe 

P-170 

Centro 

3.000 

P-230 

Moralzarzal 

4.000 

P-260 

Navacerrada 

1.700 


préstamo prestatario 

FIGURA 4.1. Las relaciones préstamo y prestatario. 
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número-préstamo 

nombre-sucursal 

importe 

nombre-cliente 

número-préstamo 

P-170 

Centro 

3.000 

Santos 

P-170 

P-230 

Moralzarzal 

4.000 

Gómez 

P-230 


FIGURA 4.2. Resultado de préstamo inner join prestatario on préstamo.número-préstamo = prestatario.número-préstamo. 


Obsérvese que el atributo número-préstamo apa¬ 
rece dos veces en la figura (la primera aparición es 
debida a la relación préstamo y la segunda a presta¬ 
tario). La norma SQL no requiere que los nombres de 
atributo en los resultados sean únicos. Se debería usar 
una cláusula as para asignar nombres únicos de atri¬ 
butos en los resultados de las consultas y subconsul¬ 
tas. 

Renombramos la relación resultado de una reunión 
y los atributos de la relación resultado utilizando la cláu¬ 
sula as, como se ilustra a continuación: 

préstamo inner join prestatario on 
préstamo.número-préstamo 
= prestatario.número-préstamo 
as ps (sucursal, número-préstamo, importe, 
cliente, número-préstamo-cliente) 

La segunda aparición de número-préstamo se ha renom¬ 
brado como número-préstamo-cliente. El orden de los 
atributos en el resultado de una reunión natural es impor¬ 
tante a la hora de renombrarlos. 

A continuación se muestra un ejemplo del uso de la 
operación reunión extema por la izquierda (left outer 
join): 

préstamo left outer join prestatario on 
préstamo.número-préstamo 
= prestatario.número-préstamo 

La reunión externa por la izquierda se calcula del modo 
siguiente. Primero se calcula el resultado de la reunión 
interna, como se vio anteriormente. A continuación, 
para cada tupia t de la unión interna, perteneciente a la 
relación del lado izquierdo (préstamo) que no encaje 
con ninguna tupia de la relación del lado derecho (pres¬ 
tatario), se añade al resultado de la reunión una tupia 
r, como se indica a continuación. Los atributos de la 
tupia r que se derivan de la relación del lado izquierdo 
se rellenan con los valores de la tupia t y el resto de los 
atributos de r se rellenan con valores nulos. La rela¬ 
ción resultante se muestra en la Figura 4.3. Las tupias 
(P-170, Centro, 3.000) y (P-230, Moralzarzal, 4.000) 


se reúnen con las tupias de prestatario y aparecen en 
el resultado de la reunión interna, y por ello en el resul¬ 
tado de la reunión externa por la izquierda. Por otra 
parte, la tupia (P-260, Navacerrada, 1.700) no encaja 
con ninguna tupia de prestatario en la reunión natural 
y por eso en el resultado de la reunión externa por la 
izquierda aparece la tupia (P-260, Navacerrada, 1.700, 
nuil, nuil). 

Finalmente, se incluye un ejemplo del uso de la ope¬ 
ración reunión natural (natural join). 

préstamo natural inner join prestatario 

Esta expresión calcula la reunión natural de dos rela¬ 
ciones. El único nombre de atributo común en présta¬ 
mo y prestatario es número-préstamo. El resultado de 
la expresión anterior se muestra en la Figura 4.4. Este 
resultado es similar al resultado de la reunión interna 
con la condición on mostrada en la Figura 4.2, puesto 
que tienen la misma condición de reunión. Sin embar¬ 
go, el atributo número-préstamo aparece sólo una vez 
en el resultado de la reunión natural, mientras que apa¬ 
rece dos veces en el resultado de la reunión con la con¬ 
dición on. 

4.10.2 Tipos y condiciones de reunión 

En el Apartado 4.10.1 se muestran ejemplos de los 
operadores de reunión incluidos en SQL-92. Las ope¬ 
raciones de reunión toman como entrada dos relacio¬ 
nes y devuelven como resultado otra relación. Aun¬ 
que las expresiones de reunión externa se usan 
normalmente en la cláusula from, se pueden utilizar 
en cualquier lugar en el que cabría usar cualquier otra 
relación. 

Cada variante de las operaciones de reunión en SQL- 
92 está formado por un tipo de reunión y una condición 
de reunión. La condición de reunión indica las tupias 
pertenecientes a las dos relaciones que encajan y los 
atributos que se incluyen en el resultado de la reunión. 
El tipo de reunión define cómo se tratan las tupias de 
cada relación que no encajan con ninguna tupia de la otra 
relación (basado en la condición de reunión). En la Figu- 


número-préstamo 

nombre-sucursal 

importe 

nombre-cliente 

número-préstamo 

P-170 

Centro 

3.000 

Santos 

P-170 

P-230 

Moralzarzal 

4.000 

Gómez 

P-230 

P-260 

Navacerrada 

1.700 

nuil 

nuil 


FIGURA 4.3. Resultado de préstamo left outer join prestatario on préstamo.número-préstamo = prestatario.número-prés¬ 
tamo. 
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número-préstamo 

nombre-sucursal 

importe 

nombre-cliente 

P-170 

Centro 

3.000 

Santos 

P-230 

Moralzarzal 

4.000 

Gómez 


FIGURA 4.4. Resultado de préstamo ¡nner join prestatario. 


ra 4.5 se muestran algunos de los tipos y condiciones 
de reunión. El primer tipo de reunión es la reunión inter¬ 
na y los otros tres son tres tipos de reuniones externas. 
Las tres condiciones de reunión son: la reunión natu¬ 
ral y la condición on, ya vistas anteriormente, y la con¬ 
dición using, que se verá más adelante. 

El uso de una condición de reunión es obligatorio en 
las reuniones extemas, pero es opcional en las reunio¬ 
nes intemas (ya que si se omite, el resultado será el pro¬ 
ducto cartesiano de las dos relaciones). La palabra cla¬ 
ve natural aparece sintácticamente delante del tipo de 
reunión, como se mostró anteriormente, mientras que 
las condiciones on y using aparecen al final de la expre¬ 
sión de reunión. Las palabras clave inner y outer son 
opcionales, ya que el resto del tipo de reunión permite 
deducir si la reunión es una reunión interna o externa. 

El significado de la condición de reunión natural, 
en términos de las tupias de las relaciones que encajan, 
es inmediato. La ordenación de los atributos, dentro del 
resultado de la reunión natural es el siguiente: los atri¬ 
butos de reunión (es decir, los atributos comunes a las 
dos relaciones) aparecen en primer lugar, en el orden en 
el que aparezcan en la relación del lado izquierdo. A con¬ 
tinuación están los demás atributos que no son de reu¬ 
nión de la relación del lado izquierdo y, al final, todos 
los atributos que no son de reunión de la relación del 
lado derecho de la relación. 

El tipo de relación reunión extema por la derecha (right 
outer join) es simétrico al de reunión externa por la 
izquierda (left outer join). Las tupias de la relación del 
lado derecho que no encajen con ninguna tupia de la rela¬ 
ción del lado izquierdo se rellenan con valores nulos y se 
añaden al resultado de la reunión extema por la derecha. 

La siguiente expresión es un ejemplo de la combi¬ 
nación de la condición de reunión natural con el tipo de 
reunión externa por la derecha. 

préstamo natural right outer join prestatario 

El resultado de la expresión anterior se muestra en la 
Ligura 4.6. Los atributos del resultado se definen por el 
tipo de reunión, que es una reunión natural; así, núme- 


Tipos de reunión 


Condiciones de reunión 

inner join 


natural 

left outer join 


on <predicado> 

right outer join 
full outer join 


using ( A v A 2 , ..., A n ) 


FIGURA 4.5. Tipos y condiciones de reunión. 


ro-préstamo aparece sólo una vez. Las primeras dos 
tupias del resultado provienen de la reunión natural de 
préstamo y prestatario. La tupia de la relación del lado 
derecho (López, P-155) no encaja en la reunión interna 
con ninguna tupia de la relación del lado izquierdo (prés¬ 
tamo). Así, la tupia (P-155, nuil, López) aparece en el 
resultado de la reunión. 

La condición de reunión using (A U A 2 ,..., A n ) es simi¬ 
lar a la condición de reunión natural, salvo en que los 
atributos de reunión en este caso son A { , A 2 ,...,A n , en 
lugar de todos los atributos comunes de ambas relacio¬ 
nes y aparecen sólo una vez en el resultado de la unión. 

El tipo de reunión externa completa (full outer join) 
es una combinación de los tipos de reunión externa por 
la derecha y por la izquierda. Después de calcular el 
resultado de la reunión interna, las tupias de la relación 
del lado izquierdo que no encajen con ninguna tupia de 
la relación del lado derecho se completan con valores 
nulos y se añaden al resultado. De forma análoga, las 
tupias de la relación del lado derecho que no encajen 
con ninguna tupia de la relación del lado izquierdo, se 
completan con valores nulos y se añaden al resultado. 

Por ejemplo, la Ligura 4.7 muestra el resultado de la 
expresión 

préstamo full outer join prestatario using 
( número-préstamo) 

Otro ejemplo del uso de la operación reunión externa 
es la consulta: «Listar todos los clientes que poseen una 
cuenta pero no tienen un préstamo en el banco». Esta 
consulta se puede formular como sigue: 

select i-NC 

from (impositor left outer join prestatario 
on impositor. nombre-cliente 
= prestatario.nombre-cliente) 
as db 1 (i-NC, número-cuenta, p-NC, 
número-préstamo) 

where p-NC is nuil 

De forma análoga, la consulta «Listar todos los clien¬ 
tes que tienen o bien una cuenta o un préstamo en el 
banco (pero no ambos)» podría formularse usando el 
operador de reunión natural extema completa, del modo 
siguiente: 

select nombre-cliente 

from (impositor natural full outer join prestatario) 
where número-cuenta is nuil or número-préstamo 
is nuil 
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número-préstamo 

nombre-sucursal 

importe 

nombre-cliente 

P-170 

Centro 

3.000 

Santos 

P-230 

Moralzarzal 

4.000 

Gómez 

P-155 

nuil 

nuil 

López 


FIGURA 4.6. Resultado de préstamo natural right outer join prestatario. 


SQL-92 proporciona además otros dos tipos de reu¬ 
nión, llamados cross join (reunión cruzada) y unión 
join (reunión de unión). El primero es equivalente a una 


reunión interna sin condición de reunión; el segundo es 
equivalente a una reunión externa completa con condi¬ 
ción falsa, es decir, donde la reunión interna es vacía. 


4.11. LENGUAJE DE DEFINICIÓN DE DATOS 


En muchos de nuestros análisis sobre SQL y bases de 
datos relaciónales hemos aceptado un conjunto de rela¬ 
ciones como predefinidas. Por supuesto, el conjunto de 
relaciones en una base de datos se debe especificar en 
términos de un lenguaje de definición de datos (LDD). 

El LDD de SQL permite la especificación no sólo de 
un conjunto de relaciones, sino también de alguna infor¬ 
mación relativa a esas relaciones, incluyendo: 

• El esquema de cada relación 

• El dominio de valores asociado a cada atributo 

• Las restricciones de integridad 

• El conjunto de índices que se deben mantener por 
cada relación 

• Información de seguridad y autorización para cada 
relación 

• La estructura de almacenamiento físico de cada 
relación en disco. 

Se analizará a continuación la definición de esquemas y 
de dominios de valores; el análisis de las demás carac¬ 
terísticas del LDD de SQL se realizará en el Capítulo 6. 

4.11.1. Tipos de dominios en SQL 

La norma SQL soporta un conjunto de tipos de domi¬ 
nios predefinidos, que incluye los siguientes: 

• char (n) es una cadena de caracteres de longitud 
fija, con una longitud n especificada por el usua¬ 
rio. También se puede utilizar la palabra comple¬ 
ta character. 

• varchar (n ) es una cadena de caracteres de longi¬ 
tud variable, con una longitud n especificada por 


el usuario. También se puede utilizar la forma com¬ 
pleta character varying.. 

• int es un entero (un subconjunto finito de los ente¬ 
ros, que es dependiente de la máquina). También 
se puede usar la palabra completa integer. 

• smallint es un entero pequeño (un subconjunto del 
dominio de los enteros, también dependiente de la 
máquina). 

• numeric (p,d) es un número en coma flotante, cuya 
precisión la especifica el usuario. El número está 
formado por p dígitos (más el signo), y de esos p 
dígitos, d pertenecen a la parte decimal. Así, nume¬ 
ric (3,1) permite que el número 44,5 se almacene 
exactamente, mientras que los números 444,5 y 
0,32 no se pueden almacenar exactamente en un 
campo de este tipo. 

• real, double precisión son respectivamente núme¬ 
ros en coma flotante y números en coma flotante 
de doble precisión, con precisión dependiente de 
la máquina. 

• float (n) es un número en coma flotante, cuya pre¬ 
cisión es de al menos n dígitos. 

• date es una fecha del calendario, que contiene un 
año (de cuatro dígitos), un mes y un día del mes. 

• time es la hora del día, expresada en horas, minu¬ 
tos y segundos. Se puede usar una variante, 
timeí/ó, para especificar el número de dígitos deci¬ 
males para los segundos (el número predetermi¬ 
nado es 0). También es posible almacenar la infor¬ 
mación del uso horario junto al tiempo. 

• timestamp es una combinación de date y time. 
Se puede usar una variante, timestamp(/?), para 
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nombre-sucursal 

importe 

nombre-cliente 

P-170 

Centro 
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P-155 

nuil 
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FIGURA 4.7. Resultado de préstamo full outer join prestatario using ( número-préstamo). 
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especificar el número de dígitos decimales para los 
segundos (el número predeterminado es 6). 

Los valores de fecha y hora se pueden especificar como: 

date ‘2001-04-25’ 
time ‘09:30:00’ 

timestamp ‘2001-04-25 10:29:01.45’ 

Las fechas se deben especificar en el formato año segui¬ 
do de mes y de día, como se muestra. El campo segun¬ 
dos de time y timestamp puede tener parte decimal, como 
se ha mostrado. Se puede usar una expresión de la forma 
cast e as t para convertir una cadena de caracteres (o una 
expresión de tipo cadena) e al tipo í, donde t es date, time 
o timestamp. La cadena debe estar en el formato ade¬ 
cuado como se indicó al comienzo de este párrafo. 

Para extraer campos individuales de un valor d date 
o time se puede usar extract {campo from d), donde 
campo puede ser year, month, day, hour, minute o 
segundo. 

Las cadenas de caracteres de longitud variable, la 
fecha y la hora no forman parte de la norma SQL. 

SQL permite realizar operaciones de comparación 
sobre todos los dominios que se listan aquí, y permite 
realizar operaciones aritméticas y de comparación sobre 
los diferentes dominios numéricos. SQL también pro¬ 
porciona un tipo de datos llamado interval y permite 
realizar cálculos basados en fechas, horas e intervalos. 
Por ejemplo, si x e y son del tipo date, entonces x-y será 
un intervalo cuyo valor es el número de días desde la 
fecha x hasta la y. De forma análoga, al sumar o restar 
un intervalo de una fecha u hora, se obtendrá como resul¬ 
tado otra fecha u hora, respectivamente. 

A menudo es útil poder comparar valores de domi¬ 
nios compatibles. Por ejemplo, como cada entero per¬ 
teneciente al tipo smallint es un entero, una compara¬ 
ción x < y, donde x es de tipo smallint e y es de tipo int 
(o viceversa), es válida. Este tipo de comparación se lle¬ 
va a cabo transformando primero el número x en un 
entero. Una transformación de este tipo se denomina 
coerción. La coerción de tipos se usa normalmente en 
los lenguajes de programación comunes, así como en 
los sistemas de bases de datos. 

Como ejemplo, supóngase que el dominio de nom¬ 
bre-cliente es una cadena de caracteres de longitud 20 
y que el dominio de nombre-sucursal es una cadena de 
caracteres de longitud 15. Aunque las longitudes de las 
cadenas de caracteres difieran, la norma SQL los con¬ 
siderará tipos compatibles. 

Como se estudió en el Capítulo 3, el valor nuil perte¬ 
nece a todos los dominios. Para ciertos atributos, sin 
embargo, los valores nulos pueden no ser apropiados. 
Considérese una tupia de la relación cliente donde el nom¬ 


bre-cliente es nulo. Una tupia de este tipo asociaría una 
calle y una ciudad a clientes anónimos: es decir, no con¬ 
tendrán información útil. En casos de este tipo, sería de¬ 
seable prohibir el uso de valores nulos, restringiendo el 
dominio de nombre-cliente para excluir los valores nulos. 

SQL permite incluir en la declaración de dominio de 
un atributo la especificación not nuil y de este modo se 
prohíbe la inserción de un valor nulo para ese atributo. 
Cualquier modificación de la base de datos que con¬ 
duzca a la inserción de un valor nulo en un dominio 
especificado como not nuil, generará un diagnóstico de 
error. Existen muchas situaciones en las que sería de¬ 
seable la prohibición de valores nulos. Un caso parti¬ 
cular donde es esencial prohibir valores nulos es en la 
clave primaria de un esquema de relación. De este modo, 
en el ejemplo bancario, en la relación cliente se prohi¬ 
birá el uso de valores nulos para el atributo nombre- 
cliente, que es la clave primaria de la relación. 

4.11.2. Definición de esquemas en SQL 

Un esquema de relación se define utilizando la orden 

create table: 

create table r (A { D { , A 2 D 2 ,... A n D n , 

(restricción-integridad!). 

(restricción-integridad,,)) 

donde r es el nombre de la relación, cada A¡ es el nom¬ 
bre de un atributo del esquema de relación r y D¡ es el 
dominio de los valores del atributo A¡. Las restricciones 
de integridad válidas incluyen: 

• primary key (Aj, A^,...,AjJ: la especificación de 
clave primaria dice que los atributos A¡ , A h ,. . ,,A¿ 
forman la clave primaria de la relación. Los atri¬ 
butos clave primaria deben ser no nulos y únicos', 
es decir, ninguna tupia puede tener un valor nulo 
para un atributo de la clave primaria y ningún par 
de tupias de la relación pueden ser iguales en todos 
los atributos clave primaria 1 . Aunque la especifi¬ 
cación de clave primaria es opcional, es general¬ 
mente buena idea especificar una clave primaria 
para cada relación. 

• check (P)\ la cláusula check especifica un predica¬ 
do P que debe satisfacer cada tupia de la relación. 

La orden de creación de tabla create table también 
incluye otras restricciones de integridad, que se estu¬ 
diarán en el Capítulo 6. 

En la Figura 4.8 se representa una definición parcial 
en SQL de la base de datos bancaria. Obsérvese que, al 
igual que en capítulos anteriores, no se intenta modelar 
con precisión el mundo real en el ejemplo de la base de 


1 En SQL-89, los atributos que forman la clave primaria no estaban 
declarados implícitamente como not nuil; era necesario una decla¬ 
ración explícita. 
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create table cliente 

( nombre-cliente char (20), 
calle-cliente char (30), 
ciudad-cliente char (30), 
primary key ( nombre-cliente)) 

create table sucursal 

( nombre-sucursal char (15), 
ciudad-sucursal char (30), 
activo integer, 

primary key ( nombre-sucursal ), 
check (activo >= 0)) 

create table cuenta 

( número-cuenta char (10), 
nombre-sucursal char (15), 
saldo integer, 

primary key ( número-cuenta ), 
check (saldo >= 0)) 

create table impositor 

( nombre-cliente char (20), 
número-cuenta char (10), 
primary key (nombre-cliente, número-cuenta )) 

FIGURA 4.8. Definición de datos en SQL para parte de la base 
de datos del banco. 


datos bancaria. En el mundo real, muchas personas tie¬ 
nen el mismo nombre por lo que nombre-cliente no sería 
una clave primaria de cliente; probablemente se usaría 
un id-cliente como clave primaria. Se usa nombre-clien¬ 
te como clave primaria para mantener el esquema de la 
base de datos simple y pequeño. 

Si como resultado de una inserción o modificación, 
una tupia toma valores nulos para cualquiera de los atri¬ 
butos que forman parte de la clave primaria, o si tiene 
el mismo valor que otra tupia de la relación para éstos, 
SQL notifica el error y la actualización no se lleva a 
cabo. De forma análoga ocurre lo mismo si falla la con¬ 
dición check de una tupia. 

De manera predeterminada, nuil es un valor válido 
para cualquier atributo en SQL, a menos que se especi¬ 
fique con not nuil. Un atributo se puede declarar para 
que no sea nulo de la forma siguiente. 

número-cuenta char(10) not nuil 

SQL también soporta una restricción de integridad 
unique (A h ,A h ,...,Aj,) 

La especificación unique indica que los atributos Aj , 
Aj ,... ,A¡ m forman una clave candidata; es decir, no pue¬ 
de haber dos tupias en la relación con todos los atribu¬ 
tos que forman la clave candidata iguales. Sin embar¬ 
go, se permite que los atributos que forman la clave 
candidata sean nulos, a menos que se hayan declarado 
como not nuil. Recuérdese que un valor nulo no es igual 
a ningún otro valor. El tratamiento de los valores nulos 
aquí es el mismo que para la constructora unique defi¬ 
nida en el Apartado 4.6.4. 

Un uso habitual de la cláusula check es el de asegu¬ 
rar que los valores de los atributos satisfacen unas con¬ 


diciones determinadas, constituyendo así un poderoso 
sistema de tipos. Por ejemplo, la cláusula check en la 
orden de creación de una tabla para la relación sucur¬ 
sal comprueba que el valor para el atributo activo es un 
entero positivo. Considérese el siguiente ejemplo: 

create table estudiante 

(,nombre char (15) not nuil, 

id-estudiante char (10) not nuil, 

nivel-estudios char (15) not nuil, 

primary key ( id-estudiante ), 
check ( nivel-estudios in (‘Graduado’, ‘Licenciado’, 
‘Doctorado’))) 

En este ejemplo se utiliza la cláusula check para simu¬ 
lar un tipo enumerado especificando que nivel-estudios 
debe ser «Graduado», «Licenciado» o «Doctorado». En 
el Capítulo 6 se considerarán condiciones check más 
generales, así como clases de restricciones denomina¬ 
das restricciones de integridad. 

Una relación inicialmente está vacía. Se pueden uti¬ 
lizar instrucciones de inserción para introducir datos en 
la misma. Muchas bases de datos relaciónales tienen 
utilidades de carga para la introducción de un conjunto 
inicial de tupias en una relación. 

Para borrar una relación de una base de datos SQL, 
se utiliza la orden drop table. Dicha orden borra de la 
base de datos toda la información sobre la relación eli¬ 
minada. La instrucción 

drop table r 

tiene una repercusión más drástica que 

delete from r 

La última conserva la relación r, pero borra todas sus 
tupias. La primera, no sólo borra todas las tupias de la 
relación r, sino también borra su esquema. Después de 
que r se elimine no se puede insertar ninguna tupia en 
dicha relación, a menos que su esquema se vuelva a 
crear utilizando la instrucción create table. 

En SQL-92, la instrucción alter table se utiliza para 
añadir atributos a una relación existente. La sintaxis de 
la instrucción es la siguiente: 

alter table r add A D 

donde r es el nombre de una relación existente, A es el 
nombre del atributo que se desea añadir y D es el domi¬ 
nio del atributo A. Se pueden eliminar atributos de una 
relación utilizando la orden 

alter table r drop A 

donde r es el nombre de una relación existente y A es el 
nombre de un atributo de la relación. Muchos sistemas 
de bases de datos no permiten el borrado de atributos, 
aunque sí permiten el borrado de una tabla completa. 
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4.12. SQL INCORPORADO 


SQL proporciona un lenguaje de consultas declarati¬ 
vo muy potente. La formulación de consultas en SQL 
es normalmente mucho más sencilla que la formula¬ 
ción de las mismas en un lenguaje de programación de 
propósito general. Sin embargo, el acceso a una base 
de datos desde un lenguaje de programación de pro¬ 
pósito general se hace necesario al menos por dos razo¬ 
nes: 

1. No todas las consultas pueden expresarse en SQL, 
ya que SQL no dispone del poder expresivo de 
un lenguaje de propósito general. Así, existen con¬ 
sultas que se pueden expresar en lenguajes como 
Pascal, C, Cobol o Fortran y que no se pueden 
expresar en SQL. Para formular consultas de este 
tipo, podemos utilizar SQL dentro de un lengua¬ 
je más potente. 

SQL está diseñado de tal forma que las con¬ 
sultas formuladas puedan optimizarse automá¬ 
ticamente y ejecutarse de manera eficiente (al pro¬ 
porcionar toda la potencia de un lenguaje de 
programación, la optimización automática es extre¬ 
madamente difícil. 

2. Las acciones no declarativas (como la impre¬ 
sión de un informe, la interacción con un usua¬ 
rio o el envío de los resultados de una consulta 
a una interfaz gráfica) no se pueden llevar a cabo 
desde el propio SQL. Normalmente las aplica¬ 
ciones tienen varios componentes y la consulta 
o actualización de datos es uno de ellos; los 
demás componentes se escriben en lenguajes de 
programación de alto nivel. En el caso de una 
aplicación integrada, los programas escritos en 
el lenguaje de programación deben tener la capa¬ 
cidad de acceder a la base de datos. 

La norma SQL define la utilización de SQL dentro 
de varios lenguajes de programación, tales como C, 
Cobol, Pascal, Java, PL/I y Fortran. Un lenguaje en 
el cual se introducen consultas SQL se denomina 
lenguaje anfitrión y las estructuras SQL que se admi¬ 
ten en el lenguaje anfitrión constituyen SQL incorpo¬ 
rado. 

Los programas escritos en el lenguaje anfitrión pue¬ 
den usar sintaxis SQL para acceder y actualizar datos 
almacenados en la base de datos. Esta forma incorpora¬ 
da de SQL amplía aún más la capacidad de los progra¬ 
madores de manipular la base de datos. En SQL incor¬ 
porado, la ejecución de una consulta la realiza el sistema 
de base de datos y el resultado de la misma se hace dis¬ 
ponible al programa, tupia a tupia (registro). 

Un programa con SQL incorporado debe tratarse con 
un preprocesador especial antes de la compilación. Las 
consultas de SQL incorporado se sustituyen por decla¬ 


raciones escritas en el lenguaje anfitrión y por llamadas 
a procedimientos que permiten la ejecución del acceso 
a la base de datos. Tras esta operación, el programa resul¬ 
tado se compila con el compilador del lenguaje anfi¬ 
trión. Para identificar las consultas de SQL incorpora¬ 
do, se utiliza la instrucción EXEC SQL, que tiene la 
siguiente forma: 

EXEC SQL cinstrucción de SQL incorporado 
END-EXEC 

La sintaxis exacta de las consultas en SQL incorpo¬ 
rado depende del lenguaje dentro del que se utilicen. 
Por ejemplo, cuando se utilizan instrucciones de SQL 
dentro de un programa en C, se debe utilizar un punto 
y coma en lugar de END-EXEC. La incorporación de 
SQL en Java (denominada SQLJ) usa la sintaxis 

# SQL { instrucción de SQL incorporado }; 

En el programa se incluye la instrucción SQL 
INCLUDE para identificar el lugar donde el preproce¬ 
sador debe insertar las variables especiales que se usan 
para la comunicación entre el programa y el sistema de 
base de datos. Las variables del lenguaje anfitrión se 
pueden utilizar en las instrucciones de SQL incorpora¬ 
do, pero se precederán por dos puntos (:) para distin¬ 
guirlas de las variables de SQL. 

Las instrucciones de SQL incorporado son similares 
en cuanto a la sintaxis a las instrucciones SQL que se 
han descrito en este capítulo. Sin embargo, hay varias 
diferencias que se indican a continuación. 

Para formular una consulta relacional se usa la ins¬ 
trucción declare cursor. El resultado de la consulta no 
se calcula aún. En lugar de esto, el programa debe usar 
las órdenes open y fetch (que se anal iz arán más adelante 
en este apartado) para obtener las tupias resultado. 

Considerando el esquema bancario que se ha utili¬ 
zado como ejemplo en este capítulo, supóngase que se 
tiene una variable del lenguaje anfitrión importe y que 
se desea encontrar los nombres y ciudades de residen¬ 
cia de aquellos clientes que superan esa cantidad en 
alguna de sus cuentas. Se puede escribir esta consulta 
del modo siguiente: 

EXEC SQL 

declare c cursor for 
select nombre-cliente, ciudad-cliente 
from impositor, cliente 
where impositor.nombre-cliente 

= cliente.nombre-cliente and 
cuenta.número-cuenta 
= impositor.número-cuenta and 
impositor.saldo > :importe 

END-EXEC 


109 



FUNDAMENTOS DE BASES DE DATOS 


En la consulta anterior, la variable c se denomina cur¬ 
sor de la consulta. Se utiliza esta variable para identifi¬ 
car la consulta en la instrucción open, que ocasiona que 
se evalúe la consulta, y en la instrucción fetch, que per¬ 
mite que los valores de una tupia se obtengan como 
variables del lenguaje anfitrión. 

La instrucción open para el ejemplo anterior debe¬ 
ría ser: 

EXEC SQL open c END-EXEC 

Esta instrucción hace que el sistema de base de datos 
ejecute la consulta y guarde el resultado dentro de una 
relación temporal. La consulta tiene una variable del 
lenguaje anfitrión (-.importe); la consulta usa el valor de 
la variable en el momento en que se ejecuta la instruc¬ 
ción open. 

Si se produce un error como resultado de la consul¬ 
ta SQL, el sistema de base de datos almacena un diag¬ 
nóstico de error en las variables del área de comunica¬ 
ción SQL (SQLCA), cuya declaración se hace mediante 
la instrucción SQL INCLUDE. 

Un programa de SQL incorporado ejecuta una serie 
de instrucciones fetch para obtener las tupias del resul¬ 
tado. La instrucción fetch necesita una variable del len¬ 
guaje anfitrión por cada atributo de la relación resulta¬ 
do. En el ejemplo anterior se necesita una variable para 
almacenar el valor de nombre-cliente y otra para el valor 
de ciudad-cliente. Si dichas variables fuesen nc y cc res¬ 
pectivamente, una tupia de la relación resultado se obten¬ 
dría mediante la instrucción: 

EXEC SQL fetch c into '.nc, :cc END EXEC 

A partir de este momento el programa puede manipu¬ 
lar las variables nc y cc, utilizando las facilidades pro¬ 
porcionadas por el lenguaje anfitrión. 

Un único fetch devuelve únicamente una tupia. Si 
se desean obtener todas las tupias del resultado, el pro¬ 
grama debe tener un bucle para iterar sobre todas las 
tupias. SQL incorporado ofrece una ayuda para el pro¬ 
gramador a la hora de programar esta iteración. Aun¬ 
que una relación es conceptualmente un conjunto, las 
tupias resultado de una consulta están físicamente en 
un determinado orden fijo. Cuando se ejecuta una ins¬ 
trucción open, el cursor pasa a apuntar a la primera 
tupia del resultado. Al ejecutarse una instrucción fetch, 
el cursor se actualiza, pasando a apuntar a la siguien¬ 
te tupia del resultado. Cuando no quedan más tupias 
para ser procesadas, la variable SQLSTATE en SQL¬ 
CA se establece a ‘02000’ (que significa «sin datos»). 
Una variable de SQLCA indica que ya no quedan 
tupias por analizar en el resultado. Así, se puede uti¬ 


lizar un bucle while (o el equivalente, en función del 
lenguaje anfitrión) para procesar cada tupia del resul¬ 
tado. 

La instrucción cióse se debe utilizar para indicar al 
sistema de base de datos que borre la relación temporal 
que contenía el resultado de la consulta. Para el ejem¬ 
plo anterior, la sintaxis de esta instrucción será: 

EXEC SQL cióse c END-EXEC 

Las expresiones de SQL incorporado que se utilizan 
para modificaciones (actualización, inserción y borra¬ 
do) de bases de datos no devuelven ningún resultado. 
Además, son más simples de expresar. Una instrucción 
de modificación tiene el siguiente aspecto: 

EXEC SQL <cualquier actualización, inserción 
o borrado válidos> END-EXEC 

En la expresión de modificación pueden aparecer varia¬ 
bles del lenguaje anfitrión precedidas de dos puntos. Si 
se produce un error en la ejecución de la instrucción, se 
devuelve un diagnóstico en SQLCA. 

Las relaciones de la base de datos también se pue¬ 
den actualizar con cursores. Por ejemplo, si se desea 
añadir 100 al atributo saldo de cada cuenta donde el 
nombre de sucursal sea «Navacerrada», se podría decla¬ 
rar un cursor como: 

declare c cursor for 

select * 

from account 

where nombre-sucursal = ‘Navacerrada’ 

for update 

Se puede iterar por las tupias ejecutando operaciones 
fetch sobre el cursor (como se mostró anteriormente) y 
después de obtener cada tupia se ejecuta el siguiente 
código: 

update cuenta 

set saldo = saldo +100 

where current of c 

SQL incorporado permite a un programa en el len¬ 
guaje anfitrión acceder a la base de datos, pero no pro¬ 
porciona ayuda para presentar los resultados al usua¬ 
rio o al generar informes. La mayoría de productos 
comerciales de bases de datos incluyen herramientas 
para ayudar a los programadores de aplicaciones a 
crear interfaces de usuario e informes con formato. 
Estas herramientas se estudian en el Capítulo 5 (Apar¬ 
tado 5.3). 
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4.13. SQL DINÁMICO 


El componente dinámico de SQL-92 permite que en un 
programa se construyan y realicen consultas SQL en 
tiempo de ejecución. En cambio, las instrucciones de 
SQL incorporado deben estar presentes en tiempo de 
compilación y se compilan utilizando un preprocesador 
de SQL incorporado. Por medio de SQL dinámico los 
programas pueden crear consultas SQL en tiempo de 
ejecución (tal vez basadas en datos introducidos por el 
usuario) y pueden ejecutarlas inmediatamente o dejar¬ 
las preparadas para su ejecución. La preparación de una 
instrucción SQL dinámica la compila y los usos poste¬ 
riores de la instrucción preparada usan la versión com¬ 
pilada. 

SQL define normas para incorporar las llamadas de 
SQL dinámico dentro de lenguaje anfitrión, como C, 
como se muestra en el siguiente ejemplo. 

char * prog_sql =«update cuenta set saldo 
= saldo * 1.05 
where número-cuenta = ?» 

EXEC SQL prepare prog_din from :prog_sql\ 

char cuenta[ 10] = «C-101»; 

EXEC SQL execute prog_din using : cuenta ; 

El programa de SQL dinámico contiene una interroga¬ 
ción ‘?’ que representa una variable que se debe pro¬ 
porcionar en la ejecución del programa. 

Sin embargo, esta sintaxis requiere extensiones para 
el lenguaje o un preprocesador para el lenguaje exten¬ 
dido. Una alternativa que usa ampliamente es una inter¬ 
faz para programas de aplicación para enviar las con¬ 
sultas SQL o actualizaciones a un sistema de bases de 
datos, sin realizar cambios en el propio lenguaje de pro¬ 
gramación. 

En el resto de este apartado se examinan dos normas 
de conexión a una base de datos SQL y la realización 
de consultas y actualizaciones. Una, ODBC, es una inter¬ 
faz para programas de aplicación para el lenguaje C, 
mientras que la otra es para Java. 

Para comprender estas normas es necesario com¬ 
prender el concepto de sesión SQL. El usuario o apli¬ 
cación se conecta a un servidor SQL, estableciendo una 
sesión; ejecuta una serie de instrucciones y, finalmen¬ 
te, desconecta la sesión. Así, todas las actividades del 
usuario o aplicación están en el contexto de una sesión 
SQL. Además de las órdenes normales de CSQL, una 
sesión también puede contener órdenes para compro¬ 
meter el trabajo realizado en la sesión o para retroce¬ 
dería. 

4.13.1. ODBC** 

La norma ODBC (Open Database Connectivity, conec- 
tividad abierta de bases de datos) define una forma para 
que un programa de aplicación se comunique con un 


servidor de bases de datos. ODBC define una interfaz 
para programas de aplicación (API, Application Pro- 
gram Interface) que pueden usar las aplicaciones para 
abrir una conexión con una base de datos, enviar con¬ 
sultas y actualizaciones y obtener los resultados. Las 
aplicaciones como las interfaces gráficas de usuario, los 
paquetes estadísticos y las hojas de cálculo pueden usar 
la misma API ODBD para conectarse a cualquier ser¬ 
vidor de bases de datos compatible con ODBC. 

Cada sistema de bases de datos que sea compatible 
con ODBC proporciona una biblioteca que se debe enla¬ 
zar con el programa cliente. Cuando el programa clien¬ 
te realiza una llamada a la API ODBC, el código de la 
biblioteca se comunica con el servidor para realizar la 
acción solicitada y obtener los resultados. 

La Ligura 4.9 muestra un ejemplo de código C que 
usa la API ODBC. El primer paso al usar ODBC para 
comunicarse con un servidor es configurar la conexión 
con el servidor. Para ello, el programa asigna en primer 
lugar un entorno SQL, después un manejador para 
la conexión a la base de datos. ODBC define los tipos 
HENV, HDBC y RETCODE. El programa abre a con¬ 
tinuación la conexión a la base de datos usando 
SQLConnect. Esta llamada tiene varios parámetros, 
incluyendo el manejador de la conexión, el servidor al 
que conectarse, el identificador de usuario y la contra¬ 
seña. La constante SQL_NTS denota que el argumento 
anterior es una cadena terminada con nulo. 

Una vez que se ha configurado la conexión, el pro¬ 
grama puede enviar órdenes SQL a la base de datos 
usando SQLExecDirect. Las variables del lenguaje C se 
pueden vincular a los atributos del resultado de la con¬ 
sulta, de forma que cuando se obtenga una tupia resul¬ 
tado usando SQLFetch, sus valores de atributo se alma¬ 
cenan en las variables C correspondientes. La función 
SQLBindCol realiza esta tarea; el segundo argumento 
identifica la posición del atributo en el resultado de la 
consulta, y el tercer argumento indica la conversión de 
tipos de SQL a C requerida. El siguiente argumento da 
la dirección de la variable. Para los tipos de longitud 
variables como los arrays de caracteres, los dos últimos 
argumentos dan la longitud máxima de la variable y una 
ubicación donde almacenar la longitud actual cuando 
se obtenga una tupia. Un valor negativo devuelto para 
el campo longitud indica que el valor es nuil. 

La instrucción SQLFetch está en un bucle while que 
se ejecuta hasta que SQLFetch devuelva un valor dife¬ 
rente de SQL_SUCCESS. En cada obtención de valo¬ 
res, el programa los almacena en variables C como se 
especifica en las llamadas en SQLBindCol e imprime 
estos valores. 

Al final de la sesión, el programa libera el maneja¬ 
dor, se desconecta de la base de datos y libera la cone¬ 
xión y los manejadores del entorno SQL. Un buen esti¬ 
lo de programación requiere que el resultado de cada 
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int ODBCexample() 

{ 

RETCODE error; 

HENV ent; /* entorno 7 

HDBC con; /* conexión a la base de datos 7 

SQLAIIocEnv(&ent); 

SQLAIIocConnect(ent, &con); 

SQLConnect(con, «aura.bell-labs.com», SQL NTS, «avi», SQL NTS, «avipasswd», SQL NTS); 

{ 

char nombresucursal[80]; 

float saldo; 

int lenOutl, Ien0ut2; 

HSTMT stmt; 

char * consulta = «select nombre„sucursal, sum (saldo) 
from cuenta 

group by nombre_sucursal»; 

SQLAIIocStmt(con, &stmt); 

error = SQLExecDirect(stmt, consulta, SQL NTS); 

¡f (error == SQL SUCCESS) { 

SQLBindCol(stmt, 1, SQL C CHAR, nombresucursal, 80, &lenOut1); 

SQLBindCol(stmt, 2, SQL C FLOAT, &saldo, 0 , &lenOut2); 

while (SQLFetch(stmt) >= SQL SUCCESS) { 
printf (« %s %g\n», nombresucursal, saldo); 

} 

} 

SQLFreeStmt(stmt, SQLDROP); 

} 

SQLDisconnect(con); 

SQLFreeConnect(con); 

SQLFreeEnv(ent); 

} 

FIGURA 4.9. Código de ejemplo ODBC. 

función se comprueba para asegurarse de que no haya 
errores; se han omitido la mayoría de estas comproba¬ 
ciones por brevedad. 

Es posible crear una instrucción SQL con paráme¬ 
tros; por ejemplo, considérese la instrucción insert into 
account values(?,?,?). Los interrogantes son resguar¬ 
dos para los valores que se proporcionarán después. Esta 
instrucción se puede «preparar», es decir, compilar en 
la base de datos y ejecutar repetidamente proporcio¬ 
nando los valores reales para los resguardos —en este 
caso proporcionando un número de cuenta, nombre de 
sucursal y saldo para la relación cuenta. 

ODBC define funciones para varias tareas, tales como 
hallar todas las relaciones en la base de datos y los nom¬ 
bres y tipos de las columnas del resultado de una con¬ 
sulta o una relación de la base de datos. 

De forma predeterminada, cada instrucción SQL se 
trata como una transacción separada que se compromete 
automáticamente. La llamada SQLSetConnectOp- 
tion(con, SQL_AUTOCOMMIT, 0) desactiva el compro¬ 
miso automático en la conexión con, y las transaccio¬ 
nes se deben comprometer explícitamente con 
SQLTransact(con, SQL_COMMIT) o retroceder con 
SQLTransact(con, SQL_ROLLBACK). 

Las versiones más recientes de la norma ODBC aña¬ 
den nueva funcionalidad. Cada versión define niveles 
de acuerdo que especifican subconjuntos de la funcio¬ 
nalidad definida por el estándar. Una implementación 


ODBC puede proporcionar sólo las características bási¬ 
cas o puede proporcionar características más avanzadas 
(nivel 1 o 2). El nivel 1 requiere soporte para la obten¬ 
ción de información del catálogo, como la información 
sobre las relaciones existentes y los tipos de sus atribu¬ 
tos. El nivel 2 requiere más características, como la capa¬ 
cidad de enviar y obtener arrays de valores de paráme¬ 
tros y para obtener información del catálogo más 
detallada. 

Las normas más recientes de SQL (SQL-92 y 
SQL: 1999) definen una interfaz en el nivel de llama¬ 
da (Call-Level Interface, CL1) que es similar a la inter¬ 
faz ODBC, pero con algunas pequeñas diferencias. 

4.13.2. JDBC** 

La norma JDBC define una API que pueden usar los 
programas Java para conectarse a los servidores de bases 
de datos (la palabra JDBC fue originalmente abreviatu¬ 
ra de «Java Database Connectivity» — conectividad de 
bases de datos con Java— pero la forma completa ya no 
se usa). La Ligura 4.10 muestra un ejemplo de un pro¬ 
grama Java que usa la interfaz JDBC. El programa debe 
en primer lugar abrir una conexión a una base de datos 
y después ejecutar instrucciones SQL, pero antes de 
abrir una conexión, carga los controladores adecuados 
para la base de datos usando Class.forName. El primer 
parámetro de la llamada getConnection especifica el 
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public static void ejemploJDBC (String idbd, String idusuario, String contraseña) 

{ 

try 

{ 

Class.forName («oracle.jdbc.driver.OracleDñver»); 

Connection con = DñverManager.getConnection 

(«jdbc:oracle:thin:@aura.bell-labs.com:2000:bdbanco», 
idusuario, contraseña); 

Statement stmt = con.createStatement(); 
try { 

stmt.executeUpdate( 

«insertinto cuenta values('C-9732’, ’Navacerrada’, 1200)»); 
} catch (SQLException sqle) 

{ 

System.out.println(«No se pudo insertar la tupia. » + sqle); 

} 

ResultSet rset = stmt.executeQuery 

(«select nombre__sucursal, avg (saldo) 
from cuenta 

group by nombre_sucursal>>); 
while (rset.next()) { 

System.out.pñntln(rset.qetStñnq(«nombre_sucursal») + « » + 
rset.getFloat(2)); 

> 

stmt.close(); 

con.close(); 

} 

catch (SQLException sqle) 

{ 

System.out.pñntln(«SQLException : » + sqle); 

} 

} 


FIGURA 4.10. Un ejemplo de código JDBC. 


nombre de la máquina en la que se ejecuta el servidor 
(en este caso, aura.bell-labs.com) y el número de puer¬ 
to que usa para la comunicación (en este caso, 2000). 
El parámetro también especifica el esquema de la base 
de datos a usar (en este caso, bdbanco), ya que un ser¬ 
vidor de bases de datos puede dar soporte a varios esque¬ 
mas. El primer parámetro también especifica el proto¬ 
colo a usar para la comunicación con la base de datos 
(en este caso, jdbc:oracle:thin:). Obsérvese que JDBC 
especifica sólo la API, no el protocolo de comunicación. 
Un controlador JDBC puede dar soporte a varios pro¬ 
tocolos y se debe especificar el compatible con la base 
de datos y el controlador. Los otros dos argumentos de 
getConnection son un identificador de usuario y una 
contraseña. 

El programa crea a continuación un manejador para 
la conexión y lo usa para ejecutar una instrucción SQL 
y obtener los resultados. En nuestro ejemplo, stmt.exe- 
cuteUpdate ejecuta una instrucción de actualización. El 
constructor try {...} catch {...} permite capturar cualquier 
excepción (condición de error) que surjan cuando se 
realizan las llamadas JDBC, e imprime un mensaje apro¬ 
piado para el usuario. 

El programa puede ejecutar una consulta usando 
stmt.executeQuery. Puede obtener el conjunto de filas 
en el resultado en ResultSet y leer tupia a tupia usando 
la función next() en el conjunto de resultados. La Figu¬ 
ra 4.10 muestra dos formas de obtener los valores de 


los atributos en una tupia: usando el nombre del atribu¬ 
to ( nombre-sucursal ) y usando la posición del atributo 
(2, para denotar el segundo atributo). 

También se puede crear una instrucción preparada 
en la que algunos valores se reemplacen por «?», espe¬ 
cificando que los valores actuales se proporcionarán más 
tarde. Se pueden proporcionar los valores usando setS- 
tring(). La base de datos puede compilar la consulta cuan¬ 
do esté preparada, y cada vez que se ejecute (con nue¬ 
vos valores), la base de datos puede rehusar la forma 
compilada previamente de la consulta. El fragmento de 
código de la Figura 4.11 muestra cómo se pueden usar 
las instrucciones preparadas. 

JDBC proporciona otras características, como los 
conjuntos de resultados actualizabas. Puede crear un 
conjunto de resultados actualizable a partir de una con¬ 
sulta que realice una selección o una proyección de una 


PreparedStatement pStmt = con.prepareStatement( 
«insert into cuenta values(?,?,?)»); 
pStmt.setString(1, «C-9732»); 
pStmt.setString(2, «Navacerrada»); 
pStmt.setlnt(3, 1200); 
pStmt.executeUpdate(); 
pStmt.setString(1, «C-9733»); 
pStmt.executeUpdate(); 

FIGURA 4.11. Instrucciones preparadas en código JDBC. 
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relación de la base de datos. Una actualización de una 
tupia en el conjunto de resultados es consecuencia de una 
actualización de la tupia correspondiente de la relación 
de la base de datos. JDBC también proporciona una API 


para examinar esquemas de la base de datos para encon 
trar los tipos de atributos de un conjunto de resultados. 

Para obtener más información sobre JDBC, cónsul 
tese la información bibliográfica al final del capítulo. 


4.14. OTRAS CARACTERÍSTICAS DE SQL** 


El lenguaje SQL ha crecido durante las dos décadas 
pasadas desde un lenguaje simple con pocas caracte¬ 
rísticas a un lenguaje ciertamente complejo con carac¬ 
terísticas para satisfacer a muchos tipos diferentes de 
usuarios. Se trataron los fundamentos de SQL anterior¬ 
mente en este capítulo. En este apartado se introducen 
al lector algunas de las características más complejas 
de SQL. 

4.14.1. Esquemas, catálogos y entornos 

Para comprender la motivación de los esquemas y los 
catálogos, considérese cómo se denominan los archivos 
en un sistema de archivos. Los sistemas de archivos ori¬ 
ginales eran planos; es decir, todos los archivos se alma¬ 
cenaban en un directorio. Los sistemas de archivos de 
la generación actual tienen por supuesto una estructura 
de directorios, con archivos almacenados en subdirec¬ 
torios. Para denominar unívocamente un archivo se debe 
especificar el nombre completo de la ruta del archivo, 
por ejemplo /usuar¡os/avi/db-book/capítulo4.tex. 

Al igual que en los primeros sistemas de archivos, 
los primeros sistemas de bases de datos tenían un úni¬ 
co espacio de nombres para todas las relaciones. Los 
usuarios tenían que coordinarse para asegurarse de que 
no intentaban usar el mismo nombre para relaciones 
diferentes. Los sistemas de bases de datos actuales pro¬ 
porcionan una jerarquía de tres niveles para denominar 
a las relaciones. El nivel superior de la jerarquía con¬ 
siste en catálogos, cada uno de los cuales puede conte¬ 
ner esquemas. Los objetos SQL tales como las rela¬ 
ciones y las vistas están contenidos en un esquema. 

Para realizar cualquier acción sobre una base de 
datos, un usuario (o un programa) debe en primer lugar 
conectarse a la base de datos. El usuario debe propor¬ 
cionar el nombre de usuario y generalmente una con¬ 
traseña secreta para comprobar la identidad del usua¬ 
rio, como se vio en los ejemplos de ODBC y JDBC de 
los apartados 4.13.1 y 4.13.2. Cada usuario tiene un 
catálogo y esquema predeterminados, y la combinación 
es única para el usuario. Cuando un usuario se conecta 
a un sistema de bases de datos, el catálogo y esquema 
predeterminados se configuran para la conexión; esto 
se corresponde con el directorio actual establecido para 
el directorio inicial del usuario cuando el usuario inicia 
la sesión en el sistema operativo. 

Para identificar una relación unívocamente, se debe 
usar un nombre con tres partes, por ejemplo: 


catálogo5. esquema-banco.cuenta 

Se puede omitir el componente catálogo y, en ese caso, 
la parte catálogo del nombre se considera el catálogo 
predeterminado para la conexión. Así, si catálogo5 es 
el catálogo predeterminado, se puede usar esquema- 
banco.cuenta para identificar la misma relación unívo¬ 
camente. Además, también se puede omitir el nombre 
del esquema, y la parte esquema del nombre es de nue¬ 
vo considerada como el esquema predeterminado de la 
conexión. Así, se puede usar tan solo cuenta si el catá¬ 
logo predeterminado es catálogo5 y el esquema prede¬ 
terminado es esquema-banco. 

Con varios catálogos y esquemas disponibles pue¬ 
den trabajar independientemente diferentes aplicacio¬ 
nes y usuarios sin preocuparse acerca de la coinciden¬ 
cia de nombres. Además, pueden ejecutarse varias 
versiones de una aplicación (una versión de produc¬ 
ción y otras de test) en el mismo sistema de bases de 
datos. 

El catálogo y esquema predeterminados son parte de 
un entorno SQL que se configura por cada conexión. 
El entorno también contiene el identificador de usuario 
(también conocido como identificador de autorización). 
Todas las consultas SQL habituales, incluyendo las ins¬ 
trucciones LDD y LMD operan en el contexto de un 
esquema. Los esquemas se pueden crear o eliminar 
mediante las instrucciones create schema o drop sche- 
ma. La creación y borrado de catálogos es dependien¬ 
te de la implementación y no es parte de la norma SQL. 

4.14.2. Extensiones procedimentales 
y procedimientos almacenados 

SQL proporciona un lenguaje de módulos, que permi¬ 
te definir los procedimientos en SQL. Un módulo con¬ 
tiene normalmente varios procedimientos SQL. Cada 
procedimiento tiene un nombre, parámetros opcionales 
y una instrucción SQL. Una extensión del lenguaje 
estándar SQL-92 también permite constructoras proce¬ 
dimentales, tales como for, while e if-then-else, e ins¬ 
trucciones SQL compuestas (varias instrucciones SQL 
entre begin y end). 

Los procedimientos se pueden almacenar en la base 
de datos y ejecutarse con la instrucción cali. Estos pro¬ 
cedimientos se denominan también procedimientos 
almacenados. Los procedimientos almacenados son 
particularmente útiles porque permiten que las opera- 
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ciones de la base de datos se encuentren disponibles a 
aplicaciones externas, sin exponer ninguno de los deta¬ 
lles internos de la base de datos. 


El Capítulo 9 trata las extensiones procedimentales 
de SQL, así como otras muchas características nuevas 
de SQL: 1999. 


4.15. RESUMEN 


Los sistemas de bases de datos comerciales no utili¬ 
zan los lenguajes de consulta formales descritos en el 
Capítulo 3. El ampliamente usado lenguaje SQL, que 
se ha estudiado en este capítulo, está basado en el 
álgebra relacional formal, pero con mucho «azúcar 
sintáctico». 

SQL incluye varias constructoras del lenguaje para 
las consultas sobre la base de datos. Todas las opera¬ 
ciones del álgebra relacional, incluyendo las ope¬ 
raciones del álgebra relacional extendida, se pueden 
expresar en SQL. SQL también permite la ordenación 
de los resultados de una consulta en términos de los 
atributos. 

Las relaciones de vistas se pueden definir como rela¬ 
ciones que contienen el resultado de consultas. Las 
vistas son útiles para ocultar información innecesaria 
y para recolectar información de más de una relación 
en una única vista. 

Las vistas temporales definidas con la cláusula with 
también son útiles para descomponer consultas com¬ 
plejas en partes más pequeñas y fáciles de entender. 

SQL incluye constructoras para insertar, actualizar y 
borrar información. Una transacción consiste en una 
secuencia de operaciones que deben ser atómicas. Es 
decir, todas las operaciones se realizan con éxito o 


ninguna. En la práctica, si una transacción no se pue¬ 
de completar con éxito, todas las acciones parciales 
realizadas se deshacen. 

Las modificaciones sobre la base de datos pueden con¬ 
ducir a la generación de valores nulos en las tupias. 
Se estudió cómo se podían introducir los valores nulos 
y la forma en que SQL maneja las consultas sobre las 
relaciones que contienen estos valores. 

El lenguaje de definición de datos SQL se usa para 
crear relaciones con los esquemas especificados. El 
LDD de SQL soporta varios tipos incluyendo date y 
time. Más detalles del LDD de SQL, y en particular 
su soporte de las restricciones de integridad, apare¬ 
cen en el Capítulo 6. 

Las consultas SQL se pueden llamar desde lenguajes 
anfitriones mediante SQL incorporado y dinámico. 
Las normas ODBC y JDBC definen interfaces para 
programas de aplicación para acceder a bases de datos 
SQL desde los programas en lenguaje C y Java. Los 
programadores usan cada vez más estas API para acce¬ 
der a bases de datos. 

También se vio una visión general de algunas carac¬ 
terísticas avanzadas de SQL, tales como las exten¬ 
siones procedimentales, los catálogos, los esquemas 
y los procedimientos almacenados. 


TÉRMINOS DE REPASO 


• Atomicidad 

• Catálogo 

• Cláusula as 

• Cláusula from 

• Cláusula order by 

• Cláusula select 

• Cláusula where 

• Cláusula with 

• Dominios 

• Duplicados 

• Esquema 

• Lunciones de agregación 

— avg, min, max, sum, count 

— count 


índice 

JDBC 

LDD: lenguaje de definición de datos 
LMD: lenguaje de manipulación de datos 
Modificación de la base de datos 

— Actualización de vistas 

— delete, insert, update 

ODBC 

Operaciones de conjuntos 

— {<,<=,>,>=} {some,all} 

— exists 

— unique 

Operaciones de conjuntos 

— unión, intersect, except 
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• Procedimientos almacenados 

• Relaciones derivadas (en la cláusula from) 

• SQL dinámico 

• SQL incorporado 

• Subconsultas anidadas 

• Tipos de reunión 

— natural, using, on 


— Reunión externa por la izquierda, por la derecha 
y completa 

— Reunión interna y extema 

• Transacción 

• Variable tupia 

• Valores nulos 

— Valor «desconocido» 

• Vistas 


EJERCICIOS 


4.1. Considérese la base de datos de seguros de la Figura 
4.12, donde las claves primarias se han subrayado. For¬ 
múlense las siguientes consultas SQL para esta base de 
datos relacional: 

a. Buscar el número total de las personas cuyos coches 
se han visto involucrados en un accidente en 1989. 

b. Buscar el número de accidentes en los cuales se ha 
visto involucrado un coche perteneciente a «Santos». 

c. Añadir un nuevo accidente a la base de datos; supón¬ 
gase cualquier valor para los atributos necesarios. 

d. Borrar el Mazda de «Santos». 

e. Actualizar el importe de daños del coche de matrí¬ 
cula «2002BCD» en el accidente con número de 
informe «AR2197» a 3.000 

4.2. Considérese la base de datos de empleados de la Figu¬ 
ra 4.13, donde las claves primarias se han subrayado. 
Proporciónese una expresión SQL para cada una de las 
consultas siguientes: 

a. Buscar los nombres de todos los empleados que tra¬ 
bajan en el Banco Importante. 

b. Buscar los nombres y ciudades de residencia de todos 
los empleados que trabajan en el Banco Importante. 

c. Buscar los nombres, direcciones y ciudades de resi¬ 
dencia de todos los empleados que trabajan en el 
Banco Importante y que ganan más de 10.000 €. 

d. Buscar todos los empleados que viven en la ciudad 
de la empresa para la que trabajan. 

e. Buscar todos los empleados que viven en la misma 
ciudad y en la misma calle que sus jefes. 

f. Buscar todos los empleados que no trabajan en el 
Banco Importante. 

g. Buscar todos los empleados que ganan más que cual¬ 
quier empleado del Banco Pequeño. 

h. Supóngase que las empresas pueden tener sede en 
varias ciudades. Buscar todas las empresas con sede 


persona (¡¿conductor, nombre, dirección) 
coche (matrícula , año, modelo) 
accidente (número-informe , fecha, lugar) 
es-dueño (id-conductor , matrícula) 

participó (id-conductor , coche , número-informe , importe-daños) 


empleado (nombre-empleado , calle, ciudad) 
trabaja (nombre-empleado , nombre-empresa, sueldo) 
empresa (nombre-emoresa . ciudad) 
iefe tnombre-empleado , nombre-jefe) 

FIGURA 4.13. Base de datos de empleados. 


en todas las ciudades en las que tiene sede el Ban¬ 
co Pequeño. 

i. Buscar todos los empleados que ganan más que el 
sueldo medio de los empleados de su empresa. 

j. Buscar la empresa que tiene el mayor número de 
empleados. 

k. Buscar la empresa que tiene el menor sueldo medio. 

l. Buscar aquellas empresas cuyos empleados ganan 
un sueldo más alto, en media, que el sueldo medio 
del Banco Importante. 

4.3. Considérese la base de datos relacional de la Figura 

4.13. Formúlese una expresión en SQL para cada una 

de las siguientes consultas: 

a. Modificar la base de datos de forma que Santos viva 
en Avila. 

b. Incrementar en un 10% el sueldo de todos los em¬ 
pleados del Banco Importante. 

c. Incrementar en un 10% el sueldo de todos los jefes 
del Banco Importante. 

d. Incrementar en un 10% el sueldo de todos los em¬ 
pleados del Banco Importante, a menos que su suel¬ 
do pase a ser mayor de 100.000 €, en cuyo caso se 
incrementará su sueldo sólo en un 3%. 

e. Borrar todas las tupias de la relación trabaja corres¬ 
pondientes a los empleados del Banco Importante. 

4.4. Considérense los esquemas de relación siguientes: 

R = (A, B, C) 

S = (D, E, F) 

Además, considérense las relaciones r (R) y r (S). 

Obténgase la expresión SQL equivalente a las siguien¬ 
tes consultas: 

a. Ujij 

b. o B = ll (r) 


FIGURA 4.12. Base de datos de seguros. 
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c. r x s 

d. n A>F (o c = D (r x í)) 

4.5. Sea R = (A,B,C) y sean r y r 2 relaciones sobre el esque¬ 
ma R. Proporciónese una expresión SQL equivalente a 
cada una de las siguientes consultas: 

a. r¡ U r 2 

b. r¡ (~l r 2 

c. r, - r 2 

d- n AB (r,) X] n BC (r 2 ) 

4.6. Sea/? = (A,B) y S=(A,C) y sean r(7?) y aí.S'J relaciones. 
Formúlese una expresión SQL equivalente a cada una 
de las siguientes consultas: 

a. {< a > I 3 b (< a, b > E r a b = 17)} 

b. {< a, b, c > I < a, b > E r a < a, c > E s} 

c. {< a > I 3 c (< a, c > E s a 3 ¿q, b 2 (< a, b¡ > E r a < c, 

b-,> E r a b i > />,))} 

4.7. Demuéstrese que en SQL < > all es equivalente a 

not in. 

4.8. Considérese la base de datos relacional de la Figura 
4.13. Utilizando SQL, defínase una vista que con¬ 
tenga nombre-jefe y el sueldo medio de todos los em¬ 
pleados que trabajan para ese jefe. Expliqúese por qué 
el sistema de base de datos no debería permitir que las 
actualizaciones se expresaran en términos de esta 
vista. 

4.9. Considérese la consulta SQL 

select p.a 1 
from p,rl,r2 

where p.a 1 = rl.al or p.a 1 = r2.a\ 

¿Bajo qué condiciones la consulta anterior devuelve 
los valores de p.a 1 que están tanto en rl como en r2? 
Examínense cuidadosamente los casos en los que rl.al 
o r2.a2 pueden ser nulos. 

4.10. Escríbase una consulta SQL, sin usar la cláusula with, 
para encontrar todas las sucursales donde el depósito 
total de las cuentas sea menor que la media del depó¬ 
sito total medio en todas las sucursales usando: 

a. Una consulta anidada en la cláusula from. 

b. Una consulta anidada en una cláusula having. 


4.11. Supóngase que se tiene una relación nota (estudiante, 
puntuación) y que se quiere clasificar a los estudiantes 
en función de la puntuación del modo siguiente: 

SS: si la puntuación es menor que 5 

AP: si la puntuación es mayor o igual que 5 y menor 

que 7 

NT: si la puntuación es mayor o igual que 7 y menor 
que 8,5 

SB: si la puntuación es mayor o igual que 8,5 
Escríbanse consultas para hacer lo siguiente: 

a. Mostrar la clasificación de cada estudiante, en tér¬ 
minos de la relación nota. 

b. Encontrar el número de estudiantes por clasificación. 

4.12. SQL-92 proporciona una operación n-aria denomina¬ 
da coalesce que se define del modo siguiente: 
coalesce (A l5 A 2 ,..., A n ) devuelve el primer A¡ no nulo 
en la lista A U A 2 ,... ,A n y devuelve nulo si todos ellos 
son nulos. Muéstrese cómo expresar la operación coa¬ 
lesce usando la operación case. 

4.13. Sean ay b relaciones con los esquemas A ( nombre, direc¬ 
ción, puesto ) y B ( nombre, dirección, sueldo), respecti¬ 
vamente. Indíquese cómo expresar a natural full outer 
join b, utilizando la operación full outer join con una 
condición on y la operación coalesce. Compruébese que 
la relación resultado no contiene dos copias de los atri¬ 
butos nombre y dirección y que la solución es válida 
incluso si dichos atributos de alguna tupia en a o b toman 
valor nulo para los atributos nombre o dirección. 

4.14. Dada una definición de esquema SQL para la base de 
datos de empleados de la Figura 4.13, elíjase un domi¬ 
nio apropiado para cada atributo y una clave primaria 
para cada esquema de relación. 

4.15. Escríbanse condiciones check para el esquema del ejer¬ 
cicio anterior para asegurar que: 

a. Cada empleado trabaja para una empresa con sede 
en la ciudad de residencia del empleado. 

b. Ningún empleado gana un sueldo mayor que el de 
su jefe. 

4.16. Descríbanse las circunstancias bajo las cuales se debe¬ 
ría utilizar SQL incorporado en lugar de SQL o un len¬ 
guaje de programación de propósito general. 


NOTAS BIBLIOGRÁFICAS 


Chamberlin et al. [1976] describen la versión original 
de SQL, denominada Sequel 2. Sequel 2 derivó de los 
lenguajes Square [Boyce et al., 1975] y Sequel [Cham¬ 
berlin y Boyce, 1974]. La norma SQL-86 se describe en 
ANSI [1986]. IBM [1987] proporciona la definición de 
SQL de IBM System Application Architecture. Las nor¬ 
mas oficiales de SQL-89 y de SQL-92 están disponi¬ 
bles en ANSI [1989] y ANSI [1992], respectivamente. 

SQL-92 también se define en el U.S. Dept. of Com- 
merce [1992] y en X/Open [1992, 1993]. Actualmente 


está en desarrollo la próxima versión de la norma de 
SQL, denominada SQL-3. 

Algunos libros de texto que describen el lenguaje 
SQL-92 son Date y Darwen [1997], Melton y Simón 
[1993], y Cannan y Otten [1993]. Melton y Eisenberg 
[2000] proporcionan una guía de SQLJ, JDBC y tec¬ 
nologías relacionadas. En http://www.sqlj.org se puede 
encontrar más información sobre SQLJ y software 
SQLJ. Date y Darwen [1997] y Date [1993a] incluyen 
una crítica de SQL-92. 
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Eisenberg y Melto [1999] proporcionan una visión 
general de SQL: 1999. La norma está publicada como 
una secuencia de cinco documentos de la norma 
1SO/IEC, con otras partes que describen varias exten¬ 
siones bajo desarrollo. La parte 1 (SQL/Lramework) da 
una visión general de las otras partes. La parte 2 
(SQL/Loundation) describe lo básico del lenguaje. La 
parte 3 (SQL/CL1) describe la interfaz en el nivel de lla¬ 
mada. La parte 4 (SQL/PSM) describe los módulos 
almacenados persistentes (Persistent Stored Modules, 
PSM), y la parte 5 (SQL/Bindings) describe los enlaces 
con el lenguaje anfitrión. La norma es útil para imple- 
mentadores de bases de datos, pero es difícil de leer. Si 
se necesita, se puede comprar electrónicamente en el 
sitio Web http://webstore.ansi.org. 


Muchos productos soportan las características de SQL 
además de las especificadas en las normas y muchos no 
soportan algunas características de la norma. Se puede 
encontrar más información sobre estas características en 
los manuales de usuario de SQL de los productos res¬ 
pectivos. http://java.sun.com/docs/books/tutorial es una 
fuente excelente para más información (actualizada) 
sobre JDBC y sobre Java en general. También hay dis¬ 
ponibles en este URL referencias a libros sobre Java 
(incluyendo JDBC). La API ODBC se describe en Micro¬ 
soft [1997] y Sanders [1998]. 

En los Capítulos 13 y 14 se estudia el procesamien¬ 
to de consultas SQL, incluyendo algoritmos y estudios 
de rendimiento. También aparecen las notas bibliográ¬ 
ficas relacionadas con este tema. 
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OTROS LENGUAJES RELACIONALES 


E n el Capítulo 4 se ha descrito SQL, el lenguaje relacional de mayor influencia comer¬ 
cial. En este capítulo se estudiarán dos lenguajes más: QBE y Datalog. A diferencia de 
SQL, QBE es un lenguaje gráfico donde las consultas parecen tablas. QBE y sus varian¬ 
tes se usan ampliamente en sistemas de bases de datos para computadoras personales. Datalog 
tiene una sintaxis derivada del lenguaje Prolog. Aunque actualmente no se usa de forma comer¬ 
cial, Datalog se ha utilizado en el desarrollo de diversos sistemas de bases de datos. 

En este capítulo se presentan las constructoras y conceptos fundamentales en lugar de un 
manual de usuario para estos lenguajes. Hay que tener presenta que las implementaciones indi¬ 
viduales de un lenguaje puede diferir en los detalles, o puede dar soporte sólo a un subconjun¬ 
to del lenguaje completo. 

En este capítulo también se estudian interfaces de formularios y herramientas para generar 
informes y analizar datos. Aunque no son lenguajes estrictamente hablando, forman la interfaz 
principal a una base de datos para muchos usuarios. De hecho, la mayoría de usuarios en abso¬ 
luto ejecutan consultas explícitas con un lenguaje de consulta y acceden a los datos mediante 
formularios, informes y otras herramientas de análisis de datos. 


5.1. QUERY-BY-EXAMPLE 


Query-by-Example (QBE, Consulta mediante ejem¬ 
plos) es el nombre tanto de un lenguaje de manipula¬ 
ción de datos como el de un sistema de base de datos 
que incluyó a este lenguaje. El sistema de bases de datos 
QBE se desarrolló en el Centro de investigación T. J. 
Watson de IBM, a principios de los años setenta y el 
lenguaje de manipulación de datos QBE se usó más tar¬ 
de en QMF (Query Management Facility, mecanismo 
de gestión de consultas), también de IBM. Actualmen¬ 
te, muchos de los sistemas de bases de datos para com¬ 
putadoras personales soportan variantes del lenguaje 
QBE. En este apartado se considera sólo el lenguaje de 
manipulación de datos. Tiene dos características dis¬ 
tintivas: 

1. A diferencia de muchos lenguajes de consulta y 
de programación, QBE presenta una sintaxis bidi- 
mensional. Las consultas parecen tablas. Una 
consulta en un lenguaje unidimensional (como 
SQL) se puede formular en una línea (posible¬ 
mente larga). Un lenguaje bidimensional necesi¬ 
ta dos dimensiones para la formulación de con¬ 
sultas. (Existe una versión unidimensional de 
QBE, pero no se considerará en este estudio.) 

2. Las consultas en QBE se expresan «mediante un 
ejemplo». En lugar de incluir un procedimiento 
para obtener la respuesta deseada, se usa un ejem¬ 
plo de qué es lo deseado. El sistema generaliza 
este ejemplo para obtener la respuesta a la con¬ 
sulta. 


A pesar de estas características tan poco comunes 
existe una correspondencia entre QBE y el cálculo rela¬ 
cional de dominios. 

Las consultas en QBE se expresan utilizando esque¬ 
letos de tablas. Estos esqueletos de tablas presentan 
el esquema de la relación, como se muestra en la Figu¬ 
ra 5.1. En lugar de llenar la pantalla con esqueletos de 
tablas, el usuario elige los esqueletos que necesita para 
una determinada consulta y rellena dichos esqueletos 
con filas ejemplo. Una fila ejemplo está formada por 
constantes y elementos ejemplo , que son variables de 
dominio. Para evitar confusiones, en QBE las varia¬ 
bles de dominio van precedidas por un carácter de 
subrayado (_) como en _x, y las constantes aparecen 
sin ninguna indicación particular. Este convenio con¬ 
trasta con la mayoría de los lenguajes, en los que las 
constantes se encierran entre comillas y las variables 
aparecen sin ninguna indicación. 

5.1.1. Consultas sobre una relación 

Recuperando el ejemplo bancario que se viene utili¬ 
zando en capítulos anteriores, para obtener todos los 
números de préstamo de la sucursal Navacerrada se uti¬ 
lizará el esqueleto de la relación préstamo y se rellena¬ 
rá del modo siguiente: 


préstamo 

número-préstamo 

numbre-sucursal 

importe 


P._x 

Navacerrada 
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sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 






cliente 

nombre-cliente 

calle-cliente 

ciudad-cliente 






préstamo 

número-préstamo 

n umbre-sucursal 

importe 






prestatario 

nombre-cliente 

número-préstamo 





cuenta 

número-cuenta 

nombre-sucursal 

saldo 






impositor 

nombre-cliente 

número-cuenta 





FIGURA 5.1. Esqueleto de las tablas QBE para el ejemplo bancario. 


La consulta anterior provoca que el sistema busque 
tupias en préstamo que tienen el atributo nombre-sucur¬ 
sal igual a «Navacerrada». Para cada tupia de este tipo, 
el valor del atributo número-préstamo se asigna a la 
variable x. El valor de la variable x se «imprime» (nor¬ 
malmente en pantalla), debido a que la orden P. apare¬ 
ce en la columna número-préstamo junto a la variable 
x. Obsérvese que este resultado es similar al que se 
obtendría como respuesta a la siguiente consulta del 
cálculo relacional de dominios: 

{(x) I 3 s,c ((x, s, c) E préstamo a 5 =«Navacerrada»)} 

QBE asume que una fila vacía contiene una variable 
única. Como resultado, si una variable no aparece más 
de una vez en una consulta, se puede omitir. La consulta 
anterior podría escribirse del modo siguiente: 


préstamo 

número-préstamo 

numbre-sucursal 

importe 


P. 

Navacerrada 



QBE (a diferencia de SQL) realiza eliminación auto¬ 
mática de duplicados. Para evitar la eliminación, se 
inserta la orden ALL. después de la orden P. : 


préstamo 

número-préstamo 

numbre-sucursal 

importe 


P.ALL. 

Navacerrada 



Para mostrar la relación préstamo completa, se pue¬ 
de crear una única fila con la orden P. en todos los cam¬ 
pos. De forma alternativa se puede usar una notación 
más cómoda consistente en colocar una única orden P. 
en la columna que lleva por nombre el nombre de la 
relación, es decir: 


préstamo 

número-préstamo 

numbre-sucursal 

importe 

P. 





QBE también permite formular consultas que con¬ 
lleven comparaciones aritméticas (por ejemplo >), ade¬ 
más de las comparaciones de igualdad. Por ejemplo, 
«Encontrar todos los números de préstamo de aquellos 
préstamos con una cantidad mayor que 700 €»: 


préstamo 

número-préstamo 

numbre-sucursal 

importe 


P. 


>700 


Las comparaciones sólo pueden contener una expre¬ 
sión aritmética en el lado derecho de la operación de 
comparación (por ejemplo, > (_x + _y -20)). La expre¬ 
sión puede contener tanto variables como constantes. 
El lado izquierdo de la comparación debe estar vacío. 
Las operaciones aritméticas que son compatibles con 
QBE son =,<,<,>> y - 1 . 

Obsérvese que la restricción del lado derecho a una 
única expresión aritmética implica que no se pueden 
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comparar dos variables de distinto nombre (más ade¬ 
lante se estudiará una solución a esta dificultad). 

Considérese, como otro ejemplo, la consulta «Obte¬ 
ner los nombres de todas las sucursales que no tienen 
sede en Barcelona». Esta consulta se puede formular 
del siguiente modo: 


sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 


P. 

-i Barcelona 



La función principal de las variables en QBE es la 
de obligar a ciertas tupias a tener el mismo valor en algu¬ 
nos atributos. Considérese la consulta «Obtener los 
números de préstamo de todos los préstamos pedidos 
conjuntamente por Santos y Gómez»: 


prestatario 

nombre-cliente 

número-préstamo 


Santos 

P. X 


Gómez 

X 





Para ejecutar la consulta anterior el sistema localiza todos 
los pares de tupias de la relación prestatario que coin¬ 
ciden en el atributo número-préstamo, donde el valor del 
atributo nombre-cliente es «Santos» para una tupia y 
«Gómez» para la otra. Una vez localizadas dichas tupias, 
se muestra el valor del atributo número-préstamo. 

En el cálculo relacional de dominios la consulta se 
podría escribir como: 

{( p) I 3 x ((x, p) G prestatario a x =«Santos») 
a 3 x ((x, p) G prestatario a x =«Gómez»)} 

Como otro ejemplo, considérese la consulta «Obte¬ 
ner los nombres de todos los clientes que viven en la 
misma ciudad que Santos». 


cliente 

nombre-cliente 

calle-cliente 

ciudad-cliente 


P._x 


K 


Santos 


-Y 


5.1.2. Consultas sobre varias relaciones 

QBE permite formular consultas que involucren varias 
relaciones distintas (de igual forma que el producto car¬ 
tesiano o la reunión natural en el álgebra relacional). 
Las conexiones entre varias relaciones se llevan a cabo 
a través de variables, que obligan a algunas tupias a 
tomar el mismo valor en ciertos atributos. Como ejem¬ 
plo, supóngase que se desea encontrar los nombres de 
todos los clientes que tienen un préstamo en la sucur¬ 
sal Navacerrada. Esta consulta se puede formular del 
siguiente modo: 


préstamo 

número-préstamo 

numbre-sucursal 

importe 


_x 

Navacerrada 



prestatario 

nombre-cliente 

número-préstamo 


P-y 



Para ejecutar la consulta anterior, el sistema locali¬ 
za las tupias en la relación préstamo que tienen el atri¬ 
buto nombre-sucursal igual a «Navacerrada». Para cada 
una de esas tupias, el sistema busca las tupias de la rela¬ 
ción prestatario con el mismo valor para el atributo 
número-préstamo que el mismo atributo de la tupia de 
la relación préstamo. Finalmente, se muestra el valor 
del atributo nombre-cliente de todas las tupias de la re¬ 
lación prestatario que cumplan las condiciones ante¬ 
riores. 

Se puede utilizar una técnica similar a la anterior para 
formular la consulta «Encontrar los nombres de todos 
los clientes que tienen tanto una cuenta como un prés¬ 
tamo en el banco»: 


impositor 

nombre-cliente 

número-cuenta 



ro 

i 


prestatario 

nombre-cliente 

número-préstamo 


_x 



Considérese ahora la consulta «Obtener los nombres 
de todos los clientes que tienen una cuenta en el banco 
pero que no tienen un préstamo en el mismo». En QBE 
las consultas que expresan negación se formulan con 
un signo not (->) debajo del nombre de la relación y cer¬ 
ca de una fila ejemplo: 


impositor 

nombre-cliente 

número-cuenta 



P._x 


prestatario 

nombre-cliente 

número-préstamo 

- 

_x 



Compárese la consulta anterior con la formulada 
anteriormente: «Obtener los nombres de todos los clien¬ 
tes que tienen tanto una cuenta como un préstamo en el 
banco». La única diferencia es la aparición del -> en el 
esqueleto de la tabla prestatario. Esta diferencia, sin 
embargo, tiene un efecto más amplio en el procesa¬ 
miento de la consulta. QBE busca todos los valores x 
para los cuales se cumple: 
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1. Existe una tupia en la relación impositor cuyo 
nombre-cliente es la variable de dominio x. 

2. No existe ninguna tupia en la relación prestata¬ 
rio cuyo nombre-cliente es como el de la varia¬ 
ble de dominio x. 

El símbolo -i se puede interpretar como «no existe». 

El hecho de que se coloque un -i bajo el nombre de 
la relación, en lugar de bajo el nombre del atributo es 
importante. El uso de -i bajo el nombre de un atributo 
es otro modo de expresar la condición de De este 
modo, para encontrar todos los clientes que tienen al 
menos dos cuentas se escribirá: 


impositor 

nombre-cliente 

número-cuenta 


P._x 

-Y 


_x 

-‘-Y 


La consulta anterior se lee como «Mostrar todos los 
valores de nombre-cliente que aparecen al menos en dos 
tupias, teniendo la segunda tupia un número-cuenta dife¬ 
rente del primero». 

5.1.3. Caja de condición 

Algunas veces es poco conveniente o imposible expre¬ 
sar todas las restricciones de las variables de dominio 
dentro de esqueletos de tablas. Para solucionar este pro¬ 
blema, QBE incluye una caja de condición, que per¬ 
mite expresar restricciones generales sobre cualquiera 
de las variables de dominio. QBE permite que aparez¬ 
can expresiones lógicas en una caja de condición. Los 
operadores lógicos son las palabras and y or y los sím¬ 
bolos «&» y «I». 

Por ejemplo, la consulta «Encontrar los números de 
préstamo de todos los préstamos de Santos o Gómez (o 
a ambos simultánemente)» se puede escribir como 


prestatario 

nombre-cliente 

número-préstamo 


n 

P. X 





condiciones 
n = Santos or _n Gómez 


Es posible expresar esta consulta sin usar una caja 
de condición usando P. en varias filas. Sin embargo, las 
consultas con P. en varias filas son a veces difíciles de 
entender y es mejor evitarlas. 

Como otro ejemplo, supóngase que se desea modi¬ 
ficar la última consulta del Apartado 5.1.2 del siguien¬ 
te modo: «Encontrar todos los clientes cuyo nombre no 
sea Santos y que tengan al menos dos cuentas en el ban¬ 


co». Es necesario incluir la restricción «x & Santos». 
Para hacer esto se escribe la restricción «x -i = Santos» 
en la caja de condición: 


condiciones 
x-i = Santos 


Cambiando de ejemplo, se desea obtener todos los 
números de cuenta con saldos entre 1.300 € y 1.500 €. 
Para formular esta consulta se escribirá: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 


P. 


X 






condiciones 

_x > 1300 
_x < 1500 


Considérese como otro ejemplo la consulta «Obte¬ 
ner todas las sucursales con activos superiores al acti¬ 
vo de al menos una sucursal con sede en Barcelona». 
Esta consulta se formula del siguiente modo: 


sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 


P._x 


-Y 



Barcelona 

Z 






condiciones 

-V<-Z 


QBE permite la aparición de expresiones aritméti¬ 
cas complejas dentro de una caja de condición. Se pue¬ 
de formular la consulta «Encontrar todas las sucursales 
que tienen activos al menos dos veces mayores al acti¬ 
vo de una de las sucursales con sede en Barcelona» del 
mismo modo que se formuló la consulta anterior, modi¬ 
ficando la caja de condición: 


condiciones 
_yz 2* _z 


Para obtener todos los números de cuenta de las que 
tienen un saldo entre 1.300 € y 2.000 €, pero que no 
sea exactamente igual a 1.500 €, se escribirá: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 


P. 


X 






condiciones 

x = (> 1300 and < 2000 and 1500) 
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QBE incluye un uso poco convencional de la cons¬ 
tructora or para permitir la realización de comparacio¬ 
nes con un conjunto de valores constantes. Para obte¬ 
ner todas las sucursales que tienen sede tanto en 
Barcelona como en Madrid, se escribirá: 


sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 


P. 

X 







condiciones 

x= (Barcelona or Madrid) 


5.1.4. La relación resultado 

Todas las consultas que se han formulado hasta ahora 
tienen una característica en común: los resultados que 
se muestran aparecen en un único esquema de relación. 
Si el resultado de una consulta contiene atributos de 
varios esquemas de relación, se necesita un mecanismo 
para mostrar el resultado deseado en una única tabla. 
Para este propósito se puede declarar una relación tem¬ 
poral resultado que incluya todos los atributos del resul¬ 
tado de la consulta. Para mostrar el resultado de la con¬ 
sulta basta incluir la orden P. en el esqueleto de la tabla 
resultado. 

Como ejemplo, considérese la consulta «Obtener el 
nombre de cliente, el número de cuenta y el saldo de 
todas las cuentas de la sucursal Navacerrada». En el 
álgebra relacional, esta consulta se procesará de la 
siguiente forma: 

1. Reunión de las relaciones impositor y cuenta. 

2. Proyección sobre los atributos nombre-cliente, 
número-cuenta y saldo. 

Para formular esta consulta en QBE se procede del 
siguiente modo: 

1. Se crea un esqueleto de tabla, denominado resul¬ 
tado, con los atributos nombre-cliente, número- 
cuenta y saldo. El nombre del esqueleto de tabla 
recién creado (es decir, resultado) no debe exis¬ 
tir previamente en la base de datos como nombre 
de otra relación. 

2. Se escribe la consulta. 


La consulta resultante es: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 


_K 

Navacerrada 

_z 


resultado 

nombre-cliente 

número-cuenta 

saldo 

P. 

X 

y 

z 






5.1.5. Presentación ordenada de las tupias 

QBE ofrece al usuario algún control sobre el orden en 
el que se presentan las tupias de una relación. Este con¬ 
trol se expresa mediante el uso de la orden AO (ascen- 
ding order, orden ascendente) y DO (descending order, 
orden descendente) en la columna apropiada. Así, para 
listar en orden alfabético ascendente todos los clientes 
que tienen una cuenta en el banco, escribiremos: 


impositor 

nombre-cliente 

número-cuenta 


PAO. 



QBE proporciona un mecanismo para la ordenación 
y presentación de datos en varias columnas. Para espe¬ 
cificar el orden en el que se debe llevar a cabo la orde¬ 
nación se añade a cada operador de ordenación (AO y 
DO) un número entero entre paréntesis. De este modo, 
para listar todos los números de cuenta de la sucursal 
Navacerrada en orden alfabético ascendente con sus res¬ 
pectivos saldos en orden descendente, se escribirá: 


cuenta 

nombre-sucursal 

número-cuenta 

saldo 


Navacerrada 

P.AO(I). 

P.DO(2). 


La orden P.AO(l) indica que el número de cuenta se 
debe ordenar primero y la orden P.DO(2) indica que los 
saldos de cada cuenta se deben ordenar a continuación. 

5.1.6. Operaciones de agregación 

QBE incluye los siguientes operadores de agregación: 
AVG, MAX, M1N, SUM y CNT. A todos estos operado¬ 
res se les debe añadir el sufijo .ALL, para crear un mul- 
ticonjunto en el que se llevan a cabo las operaciones de 
agregación. El operador .ALL asegura que no se elimi¬ 
nan los duplicados. Así, para encontrar el saldo total de 
todas las cuentas de la sucursal Navacerrada se escribirá: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 



Navacerrada 

P.SUM.ALL. 


Se usa el operador UNQ, para especificar que se de¬ 
sean eliminar duplicados. Así, para encontrar el núme¬ 
ro total de clientes que tienen una cuenta en el banco se 
escribirá: 


impositor 

nombre-cliente 

número-cuenta 

impositor 

nombre-cliente 

número-cuenta 


_x 

-V 


P.CNT.UNQ. 
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QBE también ofrece la posibilidad de calcular fun¬ 
ciones sobre grupos de tupias, utilizando el operador 
G., que es análogo a la constructora group by de SQL. 
Así, para calcular el saldo medio de cada sucursal se 
puede escribir: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 



P.G. 

P.AVG.ALL._x 


El saldo medio se calcula por sucursales. La orden 
.ALL de la entrada P.AVG.ALL en la columna de sal¬ 
do asegura que se están considerando todos los saldos. 
Si se desea mostrar los nombres de sucursal en orden 
ascendente se deberá sustituir P.G por P.AO.G. 

Para calcular el saldo medio de las cuentas de aque¬ 
llas sucursales con un saldo medio de cuenta mayor que 
1.200 € se añadirá la siguiente caja de condición: 


condiciones 
AVG.ALL._x> 1200 


Como último ejemplo, considérese la consulta «Obte¬ 
ner todos los clientes que tienen cuenta en cada una de 
las sucursales con sede en Barcelona»: 


impositor 

nombre-cliente 

número-cuenta 


P.G._x 

-Y 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 


-Y 

_z 



sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 


_z 

Barcelona 



w 

Barcelona 







condiciones 

CNT.UNQ.ALL._z = 
CNT.UNQ.ALL._w 


La variable de dominio w puede tomar el valor de nom¬ 
bres de sucursales con sede en Barcelona. Así, 
CNT.UNQ.ALL._w es el número de sucursales distin¬ 
tas de Barcelona. La variable de dominio z puede tomar 
el valor de aquellas sucursales tales que cumplen las 
condiciones siguientes: 

• La sucursal tiene sede en Barcelona 

• El cliente cuyo nombre es x tiene una cuenta en la 
sucursal. 


De este modo, CNT.UNQ.ALL._z es el número de 
sucursales distintas de Barcelona en las que el cliente 
de nombre x tiene una cuenta. Si CNT.UNQ.ALL._z = 
CNT.UNQ.ALL._w, entonces el cliente x debe tener al 
menos una cuenta en cada una de las sucursales con sede 
en Barcelona. En tal caso, x se incluye en el resultado 
mostrado (debido a P). 

5.1.7. Modificaciones de la base de datos 

En este apartado se mostrará cómo añadir, borrar o cam¬ 
biar información utilizando QBE. 

5.1.7.1. Borrado 

El borrado de tupias de una relación se expresa del mis¬ 
mo modo que una consulta. La diferencia principal es 
el uso de la orden D. en lugar de P. En QBE (a dife¬ 
rencia de SQL) se pueden borrar tupias enteras, así 
como valores de determinadas columnas. Cuando se 
borra información se introducen valores nulos, deno¬ 
tados por -, en algunas de las columnas. 

Una orden D. opera sólo sobre una relación. Si se 
desea borrar tupias de varias relaciones, se debe utili¬ 
zar un operador D. por cada relación. 

A continuación se incluyen algunos ejemplos de 
borrados en QBE: 

• Borrar al cliente Santos 


cliente 

nombre-cliente 

calle-cliente 

ciudad-cliente 

D. 

Santos 




• Borrar el atributo ciudad-sucursal de la sucursal cuyo 
nombre es «Navacerrada». 


sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 


Navacerrada 

D. 



Así, si antes de realizar la operación borrado, la 
relación sucursal contiene la tupia (Navacerrada, Bar¬ 
celona, 50.000), el resultado consiste en el reempla¬ 
zo de la tupia anterior por la de (Navacerrada, - , 
50.000). 

• Borrar todos los préstamos con una cantidad com¬ 
prendida entre 1.300 € y 1.500 €. 


préstamo 

número-préstamo 

numbre-sucursal 

cantidad 

D. 

-Y 


_x 


prestatario 

nombre-cliente 

número-préstamo 

D. 


-Y 
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condiciones 
x = (> 1300 and s 1500) 


Obsérvese que para borrar préstamos se deben 
borrar tupias tanto de la relación préstamo como de 
prestatario. 

• Borrar todas las cuentas de todas las sucursales de 
Barcelona 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 

D. 

K 

x 



impositor 

nombre-cliente 

número-cuenta 

D. 


-V 


sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 


X 

Barcelona 







Obsérvese que al formular un borrado se puede 
hacer referencia a otras relaciones además de aqué¬ 
llas que tienen información sobre el borrado. 

5.1.7.2. Inserción 

Para insertar datos en una relación se necesita especifi¬ 
car la tupia que se va a ser insertar o escribir una con¬ 
sulta cuyo resultado sea el conjunto de tupias que se van 
a insertar. La inserción se expresa mediante el opera¬ 
dor I. Obviamente, los valores de los atributos para las 
tupias insertadas deben ser miembros del dominio de 
los atributos. 

La inserción más sencilla es la inserción de una úni¬ 
ca tupia. Supóngase que se desea insertar la cuenta C- 
9732 en la sucursal Navacerrada con un saldo de700 €. 
Se escribirá: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 

1 . 

C-9732 

Navacerrada 

700 


También se puede insertar una tupia que sólo tenga 
información parcial. Para insertar en la relación sucur¬ 
sal información sobre una nueva sucursal de nombre 
«Capital» y con sede en «Madrid», pero con un valor 
nulo para activo, se escribirá: 


sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 

1 . 

Capital 

Madrid 



De manera más general, se puede querer insertar 
tupias basadas en el resultado de una consulta. Consi¬ 
dérese de nuevo la situación en la que se desea obse¬ 
quiar a todos los tenedores de un préstamo en la sucur¬ 
sal Navacerrada con una nueva cuenta de ahorro con 
200 € por cada cuenta de préstamo que tengan. A la 
nueva cuenta se le asignará el mismo número de cuen¬ 
ta que el número del préstamo. Se escribirá: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 

1 . 

X 

Navacerrada 

200 






impositor 

nombre-cliente 

número-cuenta 

1 . 

-Y 

_x 


préstamo 

número-préstamo 

numbre-sucursal 

importe 


_x 

Navacerrada 



prestatario 

nombre-cliente 

número-préstamo 


_K 

_x 


Para ejecutar la inserción anterior el sistema debe 
contener la suficiente información de la relación pres¬ 
tatario. A continuación debe utilizar dicha información 
para insertarla apropiadamente en la nueva tupia de las 
relaciones impositor y cuenta. 

5.I.7.3. Actualización 

Existen situaciones en las cuales se desea cambiar un 
valor en una tupia sin cambiar todos los valores de la 
misma. Para este propósito se utiliza el operador U. 
Como ocurría con la inserción y el borrado, se pueden 
elegir las tupias que se van a actualizar por medio de 
una consulta. QBE, sin embargo, no permite que los 
usuarios actualicen los campos de la clave primaria. 

Supóngase que se desea actualizar el valor de acti¬ 
vo de la sucursal Navacerrada a 10.000.000 €. Esta 
actualización se expresa del siguiente modo: 


sucursal 

nombre-sucursal 

ciudad-sucursal 

activo 


Navacerrada 


U.10000000 


El hecho de que el campo ciudad-sucursal esté vacío 
implica que no se realice actualización sobre este 
campo. 

La consulta anterior actualiza el activo de la sucur¬ 
sal Navacerrada a 10.000.000 €, sin tener en cuenta el 
antiguo valor. Existen circunstancias, sin embargo, don¬ 
de se necesita actualizar un valor utilizando el valor anti¬ 
guo. Supóngase que se va a proceder a los pagos de inte- 
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reses y que todos los saldos se han de incrementar en 
un 5%. Se escribirá: 


cuenta 

número-cuenta 

nombre-sucursal 

saldo 




U._x * 1.05 


Esta consulta indica que se recuperan de una en una 
las tupias de la relación cuenta, se determina su saldo x 
y se actualiza dicho saldo a x* 1.05. 

5.1.8. QBE de Microsoft Access 

En este apartado se revisará la versión de QBE de Micro¬ 
soft Access. Aunque QBE originalmente se diseñó para 
un entorno de visualización basado en texto, QBE de 
Access está diseñado para un entorno gráfico de visua¬ 
lización, y por lo tanto se denomina consulta gráfica 
mediante ejemplos (GQBE, Graphical Query-By- 
Example). 

La Figura 5.2 muestra una consulta de ejemplo en 
GQBE. La consulta se puede describir en español como 
«Hallar nombre-cliente, número cuenta y saldo para 
todas las cuentas de la sucursal Navacerrada». En el 
Apartado 5.1.4 se mostró cómo se expresaba en QBE. 

Una pequeña diferencia en la versión GQBE es que 
los atributos de una tabla se escriben uno debajo de otro, 
en lugar de horizontalmente. Una diferencia más impor¬ 
tante es que la versión gráfica de QBE usa una línea 
uniendo los atributos de dos tablas, en lugar de una varia¬ 


ble compartida, para especificar una condición de reu¬ 
nión (combinación, en la terminología de Microsoft). 

Una característica interesante de QBE en Access es 
que los vínculos entre tablas se crean automáticamente 
en función del nombre del atributo. En el ejemplo de la 
Figura 5.2 se añadieron las tablas cuenta e impositor. 
El atributo número-cuenta se comparte entre las dos 
tablas seleccionadas y el sistema inserta automática¬ 
mente un vínculo entre las dos tablas. En otras palabras, 
de manera predeterminada se impone una condición de 
reunión natural entre las tablas; el vínculo se puede 
borrar si no se quiere tener. El vínculo también se pue¬ 
de especificar para que denote una reunión externa natu¬ 
ral, en lugar de una reunión natural. 

Otra pequeña diferencia en QBE de Access es que 
especifica los atributos que se mostrarán en un cuadro 
separado, denominada la cuadrícula de diseño, en lu¬ 
gar de usar P. en la tabla. En esta cuadrícula también es¬ 
pecifican las selecciones según los valores de los atri¬ 
butos. 

Las consultas que implican agrupaciones y agrega¬ 
ciones se pueden crear en Access como se muestra en 
la Figura 5.3. La consulta de la figura halla el nombre, 
calle y ciudad de todos los clientes que tienen más de 
una cuenta en el banco; se vio la versión QBE de la 
consulta anteriormente en el Apartado 5.1.6. Los atri¬ 
butos de agrupación y las funciones de agregación se 
anotan en la cuadrícula de diseño. Si hay que mostrar 
un atributo, debe aparecer en la cuadrícula de diseño, 
y se debe especificar en la fila «Total» que sea un cri¬ 
terio de agrupación o que tenga una función de agre- 



FIGURA 5.2. Una consulta de ejemplo en QBE de Microsoft Access. 


126 






















































CAPÍTULO 5 OTROS LENGUAJES RELACIONALES 



FIGURA 5.3. Una consulta de agregación en QBE de Microsoft Access. 


gación aplicada. SQL tiene requisitos similares. Los 
atributos que participan en las condiciones de selec¬ 
ción pero que no se muestran se pueden marcar alter¬ 
nativamente como «Dónde» en la fila «Total», indi¬ 
cando que el atributo no es ni un atributo de agrupación 
ni de agregación. 

Las consultas se crean a través de una interfaz grá¬ 
fica de usuario seleccionando en primer lugar las tablas. 


Los atributos se pueden añadir después a la cuadrícula 
de diseño arrastrándolos y soltándolos desde las tablas. 
Las condiciones de selección, agrupación y agregación 
se pueden especificar a continuación sobre los atribu¬ 
tos de la cuadrícula de diseño. QBE de Access ofrece 
otra serie de características, incluyendo consultas para 
la modificación de la base de datos mediante inserción, 
borrado y actualización. 


5.2. DATALOG 


Datalog es un lenguaje de consultas, no procedimental, 
basado en el lenguaje de programación lógica Prolog. 
Como se hace en el cálculo relacional, el usuario des¬ 
cribe la información deseada sin especificar un proce¬ 
dimiento específico de obtención de dicha información. 
La sintaxis de Datalog se asemeja a la de Prolog. Sin 
embargo, el significado de los programas en Datalog se 
define de una manera puramente declarativa, a diferen¬ 
cia de la semántica más procedimental de Prolog. Data¬ 
log simplifica la escritura de consultas simples y hace 
más sencilla la optimización de consultas. 

5.2.1. Estructura básica 

Un programa en Datalog consiste en un conjunto de 
reglas. Antes de dar una definición formal de las reglas 
de Datalog y su significado formal consideraremos unos 
cuantos ejemplos. A continuación se muestra un ejem¬ 
plo de una regla Datalog para definir una relación de 


vistas vi que contiene los números de cuenta y los sal¬ 
dos de las cuentas de la sucursal Navacerrada cuyo sal¬ 
do es superior a 700 €: 

vl(C, S ) cuenta (C, «Navacerrada», S), S > 700 

Las reglas de Datalog definen vistas; la regla anterior 
utiliza la relación cuenta y define la relación de vistas 
vi. El símbolo se lee «si» y la coma que separa «cuen¬ 
ta (C, »Navacerrada«, S)» de «S > 700» se lee «y». Intui¬ 
tivamente, la regla se entiende del siguiente modo: 

para todo C,S 

si (C, «Navacerrada», 5) G cuenta y S > 140000 

entonces (C, S ) G vi 

Si la relación cuenta es la mostrada en la Figura 5.4, 
entonces la vista vi contiene las tupias que se muestran 
en la Figura 5.5. 
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número-cuenta 

nombre-sucursal 

saldo 

C-101 

Centro 

500 

C-215 

Becerril 

700 

C-102 

Navacerrada 

400 

C-305 

Collado Mediano 

350 

C-201 

Navacerrada 

900 

C-222 

Moralzarzal 

700 

C-217 

Navacerrada 

750 


FIGURA 5.4. La relación cuenta. 


Para calcular el saldo de la cuenta C-217 en la vista 
vi se puede formular la consulta siguiente: 

? v7(«C-217», S ) 

El resultado de la consulta anterior es: 

(C-217,750) 

Para obtener el número y el saldo de todas las cuentas de 
la vista vi con saldo superior a 800 se puede escribir: 

lvl(C,S),S> 160000 
El resultado de la consulta anterior es 
(C-201,900) 

En general puede ser necesaria más de una regla para 
definir una vista. Cada regla define un conjunto de tupias 
que debe contener la vista. Así, el conjunto de tupias de 
la vista se define como la unión de todos esos conjun¬ 
tos de tupias. El siguiente programa Datalog especifica 
los tipos de interés para las cuentas. 

tipo-interés (C,5) :- cuenta (C, N, S), S < 10000 
tipo-interés (C, 6) :- cuenta ( C, N, S), S > = 10000 

El programa tiene dos reglas que definen la vista tipo- 
interés, cuyos atributos son el número de cuenta y el 
tipo de interés. Las reglas especifican que si el saldo es 
menor que 10.000 €, el tipo de interés es 5% y si el sal¬ 
do es igual o superior a 10.000 €, entonces el tipo de 
interés es el 6%. 

Las reglas Datalog pueden utilizar la negación. Las 
reglas siguientes definen una vista c, que contiene los 
nombres de todos los clientes que tienen cuenta, pero 
no tienen ningún préstamo en el banco: 

c(N) :- impositor ( N,C) , not es-prestatario ( N ) 
es-prestatario (N) prestatario ( N,P ) 


número-cuenta 

saldo 

C-201 

C-217 

900 

750 


FIGURA 5.5. La relación vi. 


En Prolog, y en la mayoría de las implementaciones 
de Datalog, los atributos de una relación se reconocen 
por su posición y el nombre de los atributos se omite. 
Así, las reglas de Datalog son compactas en compara¬ 
ción con las consultas de SQL. Sin embargo, cuando las 
relaciones tienen un gran número de atributos o el orden 
de los atributos de una relación puede variar, la nota¬ 
ción posicional puede conducir a errores. No es difícil 
crear una sintaxis de Datalog que reconozca los atribu¬ 
tos por el nombre en lugar de por la posición. En un sis¬ 
tema de este tipo, la regla Datalog que define vi se 
podría escribir del modo siguiente: 

vi (número-cuenta C, saldo S) 

cuenta ( número-cuenta C, nombre-sucursal 
«Navacerrada», saldo S), 

S> 700 

La transición entre las dos variantes no implica un 
esfuerzo significativo disponiendo del esquema de rela¬ 
ción. 

5.2.2. Sintaxis de las reglas de Datalog 

Una vez que se han explicado informalmente las reglas 
y consultas en Datalog, se define formalmente su sin¬ 
taxis. Se utilizarán los mismos convenios que en el álge¬ 
bra relacional para denotar nombres de relaciones, de 
atributos, de constantes (tales como números o cade¬ 
nas) y de nombres de variables. Se usan letras mayús¬ 
culas y palabras con la primera letra en mayúscula para 
denotar nombres de variables, y letras minúsculas y 
palabras con la primera letra en minúscula para deno¬ 
tar los nombres de las relaciones y atributos. Algunos 
ejemplos de constantes son 4, que es un número, y «San¬ 
tos», que es una cadena; X y Nombre son variables. Un 
literal positivo tiene la siguiente forma: 

P (U h> •••. U 

donde p es el nombre de una relación con n atributos y 
i,, t 2 ,, t n son constantes o variables. Un literal nega¬ 
tivo tiene la siguiente forma: 

not p(t u t 2 , ...,t n ) 

donde la relación p tiene n atributos. El siguiente es un 
ejemplo de literal: 

cuenta (C, «Navacerrada», S) 

Los literales que contienen operaciones aritméticas 
se tratan de un modo especial. Por ejemplo, el literal B 
> 700, aunque no tiene la sintaxis descrita, puede enten¬ 
derse conceptualmente como > (B, 700), que sí tiene la 
sintaxis requerida y donde > es una relación. 

Pero ¿qué significa esta notación para las operacio¬ 
nes aritméticas como «>»? La relación > (conceptual- 
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mente) contiene tupias de la forma ( x,y ) para todos los 
posibles pares de valores x e y donde x >y. Así, (2, 1) y 
(5, -33) son tupias de la relación >. La relación > es infi¬ 
nita. Otras operaciones aritméticas (como >, =, + o -) 
se tratan también conceptualmente como relaciones. Por 
ejemplo, A = B + C se puede tratar conceptualmente 
como + (B, C, A), donde la relación + contiene todas 
las tupias (x, y, z ) tales que z =x + y. 

Un hecho tiene la siguiente forma: 

p(y» V 2 , ..., v n ) 

e implica que la tupia (v 1; v 2 ,. ■ v„) pertenece a la rela¬ 
ción p. Un conjunto de hechos de una relación se pue¬ 
de escribir utilizando la notación tabular habitual. Un 
conjunto de hechos para una relación en un esquema de 
base de datos equivale a un ejemplar del esquema 
de base de datos. Las reglas se construyen a partir de 
literales, y tienen la forma siguiente: 

P (h> h> ■ ■ ■> L) L 2 , L n 

donde cada L¡ es un literal (positivo o negativo). El li¬ 
teral p(t { , t 2 , ..., t n ) se denomina cabeza de la regla y 
el resto de los literales constituyen el cuerpo de la 
misma. 

Un programa Datalog consiste en un conjunto de 
reglas; el orden en el que se formulan las reglas es indi¬ 
ferente. Como se mencionó anteriormente, una relación 
se puede definir utilizando varias reglas. 

En la Figura 5.6 se muestra un ejemplo de un pro¬ 
grama Datalog relativamente complejo, que define el 
tipo de interés para cada cuenta de la sucursal Navace- 
rrada. La primera regla del programa define una vista 
interés, cuyos atributos son el número de cuenta y el 
interés de la cuenta. Usa la relación cuenta y la vista 
tipo-interés. Las últimas dos reglas del programa son 
reglas que ya se vieron anteriormente. 

Una vista v, se dice que depende directamente de 
una vista v 2 si v 2 se usa en la expresión que define a v v 
En el programa, la vista tipo-interés depende directa¬ 
mente de las relaciones tipo-interés y cuenta. A su 
vez, la relación tipo-interés depende directamente de 
cuenta. 

Una vista v, se dice que depende indirectamente 

de una vista v 2 si hay una secuencia de relaciones inter¬ 
medias /), i 2 ,..., i n para algún n tal que v { depende direc¬ 
tamente de ij, íj depende directamente de i 2 , y así suce¬ 
sivamente hasta que depende directamente de i n . 


En el ejemplo de la Figura 5.6, dado que hay una 
cadena de dependencias entre interés y tipo-interés has¬ 
ta cuenta, la relación interés depende indirectamente de 
cuenta. 

Finalmente, se dice que una vista v, depende de una 
vista v 2 si v, depende directa o indirectamente de v 2 . 

Se dice que una vista v es recursiva si depende de 
sí misma. Una vista que no depende de sí misma se dice 
que no es recursiva. 

Considérese el programa de la Figura 5.7. En él, la 
vista empl depende de sí misma (debido a la segunda 
regla) y por tanto es recursiva. En cambio, el programa 
de la Figura 5.6 no es recursivo. 

5.2.3. Semántica de Datalog no recursivo 

A continuación se considera la semántica formal de los 
programas Datalog. Por ahora se analizarán únicamen¬ 
te programas no recursivos. La semántica de programas 
recursivos es algo más complicada; se analizará en el 
Apartado 5.2.6. La semántica de un programa se defi¬ 
ne empezando por la semántica de una regla. 

5.2.3.I. Semántica de una regla 

Un ejemplar básico de una regla es el resultado de 
sustituir cada variable de la regla por alguna constante. 
Si una variable aparece varias veces en una regla, todas 
las apariciones de la variable se deben sustituir por la 
misma constante. Los ejemplares básicos se llaman habi¬ 
tualmente ejemplares. 

A continuación se muestra el ejemplo de definición 
de la vista vi y un ejemplar de la regla: 

vi ( C,S) cuenta ( C, «Navacerrada», S), S > 700 

vi («C-217» , 750) :- cuenta («C-217», «Navacerrada», 
750), 750 > 700 

En este ejemplo la variable C ha sido sustituida por «C- 
217» y la variable S por 750. 

Normalmente una regla tiene muchos ejemplares 
posibles. Estos ejemplares se corresponden con las diver¬ 
sas formas de asignar valores a cada variable de la regla. 
Dada la regla R siguiente: 

p (fj, t 2 , ..., t n ) :-Lj, L 2 , ..., L n 

y un conjunto de hechos / asociados a las relaciones que 
aparecen en la regla. Considérese cualquier ejemplar R' 
de la regla R: 

P(yi>v 2 i V„) l 2 , ..., l n 


interés (C, I) cuenta (C, «Navacerrada», S), 

tipo-interés (C, 7), / = S * 77 1 00. 
tipo-interés ( C, 5) cuenta ( C, N, S), S < 10000 

tipo-interés ( C, 6) cuenta ( C, N, S), S >= 10000 


empl (X, V) .-jefe (X, Y) 

empl ( X,Y) jefe ( X, Z), empl ( ZY) 

FIGURA 5.7. Programa Datalog recursivo. 


FIGURA 5.6. Programa Datalog que define el interés de las 
cuentas de la sucursal Navacerrada. 
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donde cada literal /, es de la forma q¡ (v n ,v,- 2 , .. v i n ) o 
not q¡ (v¡ 1 ,v¡ 2 , .. v i n ) y donde cada v, y cada v, ; es una 
constante. 

Se dice que el cuerpo de un ejemplar R' se satisfa¬ 
ce en / si 

1. Para cada literal positivo q¡ (v ¿1 ,v ¡2 , v,„) del 

cuerpo de R\ el conjunto de hechos I contiene el 
hecho q¡ (v u ,v¿ 2 , v,-„). 

2. Para cada literal negativo not q¡ (Vj A ,v j2 , ..v Jn ) 
del cuerpo de /?', el conjunto de hechos / no con¬ 
tiene el hecho q¡ (v^.v^, ..., v jn ). 

Se define el conjunto de hechos que se pueden infe¬ 
rir a partir de un conjunto de hechos / dado usando la 
regla R como: 

inferir (R, I ) = {p(t¡, t 2 , ..., t n ) I existe un ejemplar/?' 
de R, donde p (t¡, t 2 , ..t n ) 
es la cabeza de R' y el cuerpo de R' se 
satisface en /} 

Dado un conjunto de reglas R = {R lt R 2 , .... R n } se 
define: 

inferir (R, I ) = inferir (/?,, /) U inferir (R 2 , /) U ... U 
inferir ( R n , I) 

Dado un conjunto de hechos /, que contiene las tupias 
de la relación cuenta que se muestra en la Figura 5.4, 
un posible ejemplar de la regla ejemplo R sería: 

vi («C-217», 750) :- cuenta («C-217», «Navacerrada», 
750),750 > 700 

El hecho cuenta («C-217», «Navacerrada», 750) perte¬ 
nece al conjunto de hechos I. Además, 750 es mayor 
que 700 y así, conceptualmente, (750, 700) está en la 
relación «>». Por tanto, el cuerpo del ejemplar de la 
regla se satisface en I. Existen otros posibles ejempla¬ 
res de R y utilizándolos se comprueba que inferir (R, I ) 
tiene exactamente el conjunto de hechos para vi que se 
muestra en la Figura 5.8. 

S.2.3.2. Semántica de un programa 

Cuando una vista se define en términos de otra vista, el 
conjunto de hechos de la primera vista depende de los 
hechos de la segunda de ellas. En este apartado se asu¬ 
me que las definiciones no son recursivas: es decir, nin¬ 
guna vista depende (directa o indirectamente) de sí mis¬ 
ma. Así, se pueden superponer las relaciones de vistas 


número-cuenta 

saldo 

C-201 

C-217 

900 

750 


FIGURA 5.8. Resultado de inferir (R, /). 


en capas de la forma siguiente y se puede usar la super¬ 
posición para definir la semántica del programa. 

• Una relación está en la capa 1 si todas las relacio¬ 
nes que aparecen en los cuerpos de las reglas que 
la definen están almacenadas en la base de datos. 

• Una relación está en la capa 2 si todas las relacio¬ 
nes que aparecen en los cuerpos de las reglas que 
la definen están almacenadas en la base de datos, 
o son de la capa 1. 

• En general, una relación p está en la capa i + 1 si 
(1) no está en las capas 1,2, ..., i, y (2) todas las 
relaciones que aparecen en los cuerpos de las reglas 
que la definen están almacenadas en la base de 
datos o son de las capas 1,2, ...,/. 

Considérese el programa de la Figura 5.6. La clasi¬ 
ficación en capas de las vistas del programa se muestra 
en la Figura 5.9. La relación cuenta está en la base de 
datos. La relación tipo-interés está en la capa 1, mien¬ 
tras que todas las relaciones que se utilizan en las dos 
reglas que la definen están en la base de datos. La rela¬ 
ción cuenta-Navacerrada está también en la capa 1. Por 
último, la relación interés está en la capa 2, puesto que 
no está en la capa 1 y todas las relaciones que se utili¬ 
zan en las reglas que la definen están en la base de datos 
o en capas inferiores a la 2. 

A continuación se puede definir la semántica de un 
programa Datalog en términos de la clasificación en 
capas de las vistas. Sean las capas de un programa dado 
en el rango l,2,...,n. Sea Ri el conjunto de todas las 
reglas que definen vistas en la capa i. 

• Se define / 0 como el conjunto de los hechos alma¬ 
cenados en la base de datos e /, como 

/, = / 0 U inferir (R { , I 0 ) 

• A continuación se procede de un modo análogo, 
definiendo I 2 en términos de /, y R 2 , y así sucesi¬ 
vamente utilizando la siguiente definición: 

/«■ + i = /, U inferir (R i+Í , /,) 


Capa 2 


Capa 1 


Base de datos 



FIGURA 5.9. Clasificación en capas de las vistas. 
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• Por último, el conjunto de hechos de las vistas defi¬ 
nidos por el programa (también denominados la 
semántica del programa) se define como el con¬ 
junto de hechos /„, correspondientes a la capa más 
alta (n). 

Para el programa de la Figura 5.6, 1 0 es el conjunto 
de hechos en la base de datos e /, es el conjunto de 
hechos de la base de datos ampliado con el conjunto de 
todos los hechos que se pueden inferir de / 0 utilizando 
las reglas de la relación tipo-interés y cuenta-Navace- 
rrada. Finalmente, / 2 contiene los hechos de /,, junto 
con los hechos de la relación interés que se pueden infe¬ 
rir de los hechos en /, utilizando las reglas de la rela¬ 
ción interés. La semántica del programa, es decir, el 
conjunto de los hechos que están en cada vista, se defi¬ 
ne como el conjunto de los hechos de / 2 . 

Recuérdese que en el Apartado 3.5.3 se mostró cómo 
definir el significado de las vistas no recursivas del álge¬ 
bra relacional utilizando una técnica denominada expan¬ 
sión de vistas. La expansión de vistas se puede usar tam¬ 
bién con vistas no recursivas de Datalog; del mismo 
modo, la técnica de clasificación por capas descrita ante¬ 
riormente se puede utilizar con las vistas del álgebra 
relacional. 

5.2.4. Seguridad 

Es posible formular reglas que generen un infinito núme¬ 
ro de respuestas. Considérese la regla 

mayor (X, Y) X > Y 

Como la relación que define > es infinita, esta regla 
generaría un número infinito de hechos para la relación 
mayor, cuyo cálculo necesitaría una cantidad infinita de 
tiempo y espacio. 

El uso de la negación puede causar problemas simi¬ 
lares. Considérese la regla siguiente: 

no-en-préstamo (S, P) not préstamo ( S, P) 

La idea es que la tupia ( sucursal, número-préstamo ) está 
en la vista no-en-préstamo si no pertenece a la relación 
préstamo. Sin embargo, si el conjunto de posibles nom¬ 
bres de sucursales o el número de cuentas es infinito, la 
relación no-en-préstamo puede ser infinita. 

Por último, si existe una variable en la cabeza de la 
regla que no aparece en el cuerpo, se puede generar un 
conjunto infinito de hechos donde la variable se asigna 
a distintos valores. 

Teniendo en cuenta que estas posibilidades se pue¬ 
den producir, se exige que las reglas de Datalog cum¬ 
plan las siguientes condiciones de seguridad: 

1. Cualquier variable que aparezca en el lado izquier¬ 
do de una regla debe aparecer en un literal posi¬ 
tivo no aritmético, en el cuerpo de la misma. 


2. Cualquier variable que aparezca en un literal nega¬ 
tivo en la cabeza de una regla debe aparecer tam¬ 
bién en algún literal positivo en el cuerpo de la 
misma. 

Si todas las reglas de un programa Datalog no recur¬ 
sivo satisfacen las reglas anteriores entonces las vis¬ 
tas definidas en el programa serán finitas, siempre que 
las relaciones de la base de datos sean finitas. Las con¬ 
diciones se pueden relajar en algunos casos para per¬ 
mitir que variables de la cabeza puedan aparecer sólo 
en literales aritméticos del cuerpo. Por ejemplo, en la 
regla 

p (A) q ( B ), A = B + 1 

se puede observar que si la relación q es finita, enton¬ 
ces, por las propiedades de la adición, también lo es p, 
incluso cuando la variable A aparece sólo en un literal 
aritmético. 

5.2.5. Operaciones relaciónales en Datalog 

Las expresiones de Datalog no recursivas sin operacio¬ 
nes aritméticas son equivalentes en poder expresivo a 
las expresiones que utilizan las operaciones básicas del 
álgebra relacional (U, - , x, o, n y p). En lugar de 
demostrar formalmente ahora esta afirmación, se mos¬ 
trará mediante ejemplos cómo se pueden expresar en 
Datalog varias operaciones del álgebra relacional. En 
todos los casos se define una vista denominada consul¬ 
ta, para ilustrar las operaciones. 

Ya se ha visto anteriormente cómo llevar a cabo una 
selección utilizando reglas de Datalog. Las proyeccio¬ 
nes se llevan a cabo utilizando únicamente los atribu¬ 
tos requeridos en la parte izquierda de la regla. Para pro¬ 
yectar el atributo nombre-cuenta de la relación cuenta, 
se utilizará: 

consulta (C) :- cuenta ( C, N, S) 

Para obtener el producto cartesiano de dos relacio¬ 
nes r i y r 2 en Datalog, se puede formular la regla: 

consulta (X i ,X 2 ,...,X n , Y l ,Y 2 ,..., YJ :-r l (X l ,X 2 , ..., 
X n ), r 2 (Y x , Y 2 , ..., Y m ) 

Donde r¡ es de aridad n, r 2 es de aridad m y los Aj, X 2 , 
..., X n , Y¡, Y 2 , ..., Y m son nombres de variables, todos 
distintos. 

La unión de dos relaciones r { y r 2 (ambas de aridad 
ri), se forma del siguiente modo: 

consulta (Aj, X 2 , ...,X n ) :- r, (Aj, X 2 , ...,X n ) 
consulta (X,, X 2 , ...,X n ) :- r 2 (Aj, X 2 , ...,X n ) 

El conjunto diferencia de dos relaciones r, y r 2 se 
calcula como sigue: 
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consulta (X { , X 2 , .. X n ) r { (X { , X 2 , .. X n ), 
not r 2 (X,,X 2 , ...,X n ) 

Finalmente, obsérvese que, con la notación posicional 
usada en Datalog, el operador renombramiento p no se 
necesita. Una relación puede aparecer más de una vez 
en el cuerpo de la regla, pero en lugar de renombrar para 
dar nombres diferentes a las apariciones de la relación, 
se usan diferentes nombres de variables en las diferen¬ 
tes apariciones. 

Es posible demostrar que cualquier consulta no recur¬ 
siva de Datalog se puede expresar sin funciones arit¬ 
méticas, utilizando las operaciones del álgebra relacio- 
nal. Esta demostración se plantea como ejercicio para 
el lector. Así, se puede establecer la equivalencia de las 
operaciones básicas del álgebra relacional y Datalog no 
recursivo sin operaciones aritméticas. 

Las operaciones relaciónales extendidas de inser¬ 
ción, borrado y actualización son compatibles con cier¬ 
tas extensiones de Datalog. La sintaxis para tales ope¬ 
raciones varía entre implementaciones distintas. Algunos 
sistemas permiten el uso de + o - en la parte izquierda 
de las reglas para denotar la inserción y borrado rela¬ 
cional. Por ejemplo, se pueden trasladar todas las cuen¬ 
tas de la sucursal Navacerrada a la sucursal Madrid eje¬ 
cutando 

+ cuenta (C, «Madrid», S) cuenta ( C , 

«Navacerrada», 5) 

- cuenta (C, «Navacerrada», S ) cuenta (C, 

«Navacerrada», S) 

La operación de agregación del álgebra relacional 
extendida se ofrece en algunas implementaciones de 
Datalog. De nuevo, no existe sintaxis normalizada para 
esta operación. 

5.2.6. La recursividad en Datalog 

Diversas aplicaciones de base de datos manejan estruc¬ 
turas similares a los árboles de datos. Por ejemplo, con¬ 
sidérense los empleados de una empresa. Algunos 
empleados son jefes. Cada jefe dirige un conjunto de 
personas y cada una de esas personas puede ser a su vez 
jefe. Así, los empleados se pueden organizar en una 
estructura similar a un árbol. 

Supóngase el siguiente esquema de relación: 

Esquema-jefe = ( nombre-empleado, nombre-jefe) 

Sea jefe una relación del esquema anterior. 

Supóngase ahora que se desea obtener un listado de 
los empleados que supervisa (directa o indirectamente) 
un determinado jefe, por ejemplo Santos. Es decir, si el 
jefe de Arteaga es Benzoaga, el jefe de Benzoaga es Ere- 
jalde y el jefe de Erejalde es Santos, entonces Arteaga, 
Benzoaga y Erejalde son empleados supervisados por 
Santos. A menudo se escriben programas recursivos para 


procedure PuntoFijo-Datalog 

I = conjunto de hechos de la base de datos 

repeat 

l_Anterior = I 
1= U inferir (R, /) 
until 1 = l_Anterior 

FIGURA 5.10. Procedimiento PuntoFijo-Datalog. 


manipular árboles de datos. Utilizando la idea de la 
recursividad se puede definir el conjunto de personas 
dirigidas por Santos como se indica a continuación. Las 
personas supervisadas por Santos son (1) personas cuyo 
jefe directo es Santos y (2) las personas cuyo jefe es 
supervisado por Santos. Nótese que el caso (2) es recur¬ 
sivo. 

Se puede formular la definición recursiva anterior 
como una vista recursiva de Datalog, denominada empl- 
Santos, del modo siguiente: 

empl-Santos ( X) '-jefe (X,«Santos») 

empl-Santos (X) '-jefe (X, K), empl-Santos (Y) 

La primera regla corresponde al caso (1) y la segunda 
al caso (2). La vista empl-Santos depende de sí misma 
por la segunda regla; por eso, el programa Datalog ante¬ 
rior es recursivo. Se asumirá a partir de ahora que los 
programas de Datalog recursivos no contienen reglas 
con literales negativos. La razón se aclarará más ade¬ 
lante. Las notas bibliográficas hacen referencia a publi¬ 
caciones que describen dónde se puede utilizar la nega¬ 
ción en programas Datalog. 

Las vistas de un programa recursivo que contienen 
un conjunto de reglas R se definen exactamente como 
el conjunto de hechos I que resultan de aplicar iterati¬ 
vamente el procedimiento PuntoLijo-Datalog de la Ligu- 
ra 5.10. La recursividad en un programa Datalog se con¬ 
vierte en la iteración del procedimiento. Al final del 
procedimiento aparece inferir (R, I) U D = I, donde I) 
es el conjunto de hechos de la base de datos, e I se deno¬ 
mina punto fijo del programa. 

Considérese el programa que define empl-Santos de 
la Ligura 5.11 con la relación jefe. En la Ligura 5.12 se 
muestra el conjunto de hechos que resultan de cada ite¬ 
ración de la vista empl-Santos. En cada iteración, se cal¬ 
cula un nivel más de empleados dirigidos por Santos, 
que se añaden al conjunto empl-Santos. El procedi- 


nombre-empleado 

nombre-jefe 

Arteaga 

Benzoaga 

Conesa 

Duarte 

Erejalde 

Santos 

Ruipérez 

Benzoaga 

Erejalde 

Duarte 

Santos 

Santos 

Lara 

Lara 


FIGURA5.11. La relación jefe. 
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número de Iteración 

Tupias en empl-Santos 

0 

1 

(Duarte), (Erejalde) 

2 

(Duarte), (Erejalde), (Benzoaga), (Conesa) 

3 

(Duarte), (Erejalde), (Benzoaga), (Conesa), (Arteaga) 

4 

(Duarte), (Erejalde), (Benzoaga), (Conesa), (Arteaga) 


FIGURA 5.12. Empleados de Santos en las distintas iteraciones del procedimiento PuntoFijo-Datalog. 


miento termina cuando, tras una iteración, no se pro¬ 
duce ningún cambio en el conjunto empl-Santos, es 
decir, cuando I = I_Anterior. Como el conjunto de 
empleados y jefes es finito, en algún momento se tiene 
que alcanzar este punto fijo. En la relación jefe dada, el 
procedimiento PuntoFijo-Datalog termina después de 
la cuarta iteración, al detectar que no se ha inferido nin¬ 
gún hecho nuevo. 

Se debe verificar que, al final de cada iteración, la 
vista empl-Santos contiene aquellos empleados que tra¬ 
bajan bajo la supervisión de Santos. Para obtener los 
nombres de los empleados supervisados por Santos, se 
puede utilizar la siguiente consulta: 

? empl-Santos (N) 

Para que se entienda mejor el procedimiento Punto¬ 
Fijo-Datalog hay que señalar que una regla infiere nue¬ 
vos hechos a partir de un conjunto de hechos dado. Fa 
iteración comienza con un conjunto de hechos I que 
corresponden a los hechos de la base de datos. Estos 
hechos se sabe a ciencia cierta que son verdaderos pero 
pueden existir otros hechos igualmente verdaderos 1 . 
A continuación, se aplica el conjunto de reglas R del 
programa Datalog, partiendo del conjunto de hechos 
verdaderos I. Eos hechos inferidos se añaden a I y las 
reglas se usan de nuevo para hacer nuevas inferencias. 
Este proceso se repite hasta que no se infieren nuevos 
hechos. 

Se puede demostrar para programas Datalog segu¬ 
ros que existe un punto a partir del cual no se pueden 
derivar más hechos verdaderos; es decir, para algún k, 
I k+ j = 4- En este punto se tiene el conjunto final de 
hechos verdaderos. Además, dado un programa Data¬ 
log y la base de datos correspondiente, el procedi¬ 
miento de punto fijo infiere todos los hechos verda¬ 
deros que se pueden inferir partiendo de dicha base de 
datos. 

Si un programa recursivo contiene una regla con un 
literal negativo puede surgir un problema. Recuérdese 
que cuando se hizo una inferencia usando un ejemplar 
básico de una regla, por cada literal negativo not q en 


el cuerpo de la regla se comprobó que q no estaba pre¬ 
sente en el conjunto de hechos I. Esta comprobación 
asume que q no se puede inferir después. Sin embargo, 
en la iteración del punto fijo, el conjunto de hechos I 
crece en cada iteración, e incluso si q no está presente 
en I en una iteración, puede aparecer más tarde. Así, 
podríamos haber hecho una inferencia en una iteración 
que no se pudo hacer en una iteración anterior, y la infe¬ 
rencia fue incorrecta. Se requiere que un programa recur¬ 
sivo no contenga literales negativos para evitar estos 
problemas. 

En lugar de crear una vista para los empleados super¬ 
visados por Santos, se puede crear la vista empl, más 
general, que contenga todas las tupias ( X,Y) tales que X 
sea directa o indirectamente supervisado por Y, utili¬ 
zando el siguiente programa (Figura 5.7): 

empl ( X , Y) -jefe (X, Y) 

empl ( X, Y) '-jefe ( X , Z), empl (Z, Y) 

Para obtener los empleados supervisados directa o indi¬ 
rectamente por Santos, se utilizará la consulta 

? empl (X, «Santos») 

que devuelve para X el mismo conjunto de valores de 
la vista empl-Santos. La mayoría de las implementa- 
ciones de Datalog cuentan con sofisticados optimiza- 
dores de consultas y motores de evaluación que pueden 
evaluar la consulta anterior a la misma velocidad que 
evaluarían la vista empl-Santos. 

La vista empl definida anteriormente se denomina 
cierre transitivo de la relación jefe. Si se sustituye¬ 
ra la relación jefe por cualquier otra relación binaria 
R , el programa anterior definiría el cierre transitivo 
de R. 

5.2.7. La potencia de la recursividad 

Datalog con recursividad tiene mayor potencia expre¬ 
siva que Datalog sin recursividad. En otras palabras, 
existen consultas en la base de datos que se pueden resol- 


1 La palabra «hecho» se usa en un sentido técnico para indicar la per¬ 
tenencia de una tupia a una relación. Así, en el sentido de Datalog 
para «hecho», un hecho puede ser cierto (la tupia está realmente en 
la relación) o falso (la tupia no está en la relación). 
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ver utilizando recursividad, pero que no se pueden resol¬ 
ver sin utilizarla. Por ejemplo, en Datalog no se puede 
expresar el cierre transitivo sin utilizar recursividad (o, 
igualmente, en SQL o QBE sin recursividad). Considé¬ 
rese el cierre transitivo de la relación jefe. Intuitiva¬ 
mente, con un número fijo de reuniones pueden obte¬ 
nerse solamente aquellos empleados que están ese 
número ñjo de niveles por debajo de cualquier jefe (esta 
afirmación no se demostrará en este texto). Como cual¬ 
quier consulta no recursiva tiene un número fijo de reu¬ 
niones, existe un límite en el número de niveles de 
empleados que se pueden obtener mediante esa con¬ 
sulta. Si el número de niveles de empleados de la rela¬ 
ción jefe es mayor que el límite de la consulta, no se 
encontrarán algunos niveles de empleados. Así, un pro¬ 
grama Datalog no recursivo no puede expresar el cie¬ 
rre transitivo. 

Una alternativa a la recursividad es utilizar un 
mecanismo externo, como SQL incorporado, para ite¬ 
rar una consulta no recursiva. La iteración implementa 
el bucle del algoritmo de punto fijo de la Ligura 5.10. 
De hecho, así es como se implementan este tipo de 
consultas en los sistemas de bases de datos que no per¬ 
miten la recursividad. Sin embargo, la formulación de 
estas consultas utilizando iteración es más complica¬ 
da que utilizando recursividad y la evaluación utili¬ 
zando recursividad puede optimizarse para que se eje¬ 
cute más rápidamente que la evaluación utilizando 
iteración. 

La potencia expresiva de la recursividad debe apro¬ 
vecharse con cuidado. Es relativamente fácil escribir 
programas recursivos que generen un número infinito 
de hechos, como se muestra en el siguiente programa: 

número (0) 

número (A) número (B), A = B + 1 

El programa genera número (n) para cualquier n 
positivo, es decir, para un conjunto infinito. La segun¬ 
da regla del programa no cumple la condición de segu¬ 
ridad descrita en el Apartado 5.2.4. Los programas que 
cumplen la condición de seguridad terminarán, inclu¬ 
so si son recursivos, siempre que las relaciones de la 
base de datos sean finitas. Para programas de este tipo, 
las tupias en las vistas pueden contener únicamente 
constantes de la base de datos, y por ello serán finitas. 
Lo opuesto no es cierto; es decir, existen programas 
que no satisfacen la condición de seguridad, pero que 
terminan. 

5.2.8 Recursividad en otros lenguajes 

La norma SQL: 1999 soporta una forma limitada de 
recursión usando la cláusula with recursive. Supónga¬ 
se que la relación jefe tiene los atributos emp y mgr. 
Podemos encontrar cada par ( X, Y) tal que X tenga como 
jefe directo o indirecto a Y usando esta consulta 
SQL: 1999: 


with recursive empl (emp, jef) as ( 
select emp, jef 
from jefe 
unión 

select emp, empl.jef 
from jefe, empl 
where jefe.jef=empl.emp 

) 

select * 
from empl 

Recuérdese que la cláusula with se usa para definir 
una vista temporal cuya definición sólo está disponible 
para la consulta en la que se define. La palabra clave 
adicional recursive especifica que la vista es recursiva. 
La definición SQL de la vista empl es equivalente a la 
versión Datalog que se vio en el Apartado 5.2.6. 

El procedimiento PuntoLijo-Datalog utiliza iterati¬ 
vamente la función inferir (R, /) para obtener hechos 
verdaderos dado un programa Datalog recursivo. Aun¬ 
que se considera únicamente el caso de los programas 
sin literales negativos, el procedimiento también se pue¬ 
de utilizar en las vistas definidas utilizando otros len¬ 
guajes, como SQL o el álgebra relacional, siempre que 
las vistas satisfagan las condiciones descritas a conti¬ 
nuación. Independientemente del lenguaje que se uti¬ 
lice para definir una vista V, la vista se puede conside¬ 
rar definida por una expresión EV que, dado un conjunto 
de hechos I, devuelve un conjunto de hechos EV (/) 
para la relación V. Dado un conjunto de vistas R (defi¬ 
nidas en cualquier lenguaje), se puede definir una fun¬ 
ción inferir (R, /) que devuelva I U (j V£R E v (/). 
La función anterior es similar a la función inferir de 
Datalog. 

Una vista V es monótona si, dado cualquier par de 
conjuntos de hechos /, e / 2 , tales que 7j C I 2) entonces 
E v (/[) C E v (/ 2 ), donde E v es la expresión utilizada para 
definir V. Análogamente, se dice que la función inferir 
es monótona si 

/,£/, = > inferir (R, Ij) C inferir (R, / 2 ) 

Así, si inferir es monótona, dado un conjunto de hechos 
I 0 que es un subconjunto de hechos verdaderos, se pue¬ 
de asegurar que todos los hechos del conjunto inferir 
(R, I 0 ) son verdaderos. Utilizando el mismo razona¬ 
miento del Apartado 5.2.6, se puede demostrar que el 
procedimiento PuntoLijo-Datalog es correcto (es decir, 
calcula sólo los hechos verdaderos), ya que la función 
inferir es monótona. 

Las expresiones del álgebra relacional que utilizan 
los operadores n, o, x, M , U, D o p son monótonas. 
Las vistas recursivas se pueden definir utilizando dichas 
expresiones. 

Sin embargo, las expresiones relaciónales que utili¬ 
zan el operador - no son monótonas. Por ejemplo, sean 
jefe [ y jefe 2 relaciones con el mismo esquema que la 
relación jefe. Sea 
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I\ = {jefe¡ («Arteaga», «Benzoaga »),jefe l 

(«Benzoaga», «Erejalde»), jefe 2 («Arteaga», 
«Benzoaga»)} 

y sea 

/ 2 = {jefe x («Arteaga», «Benzoaga»),}^! 

(«Benzoaga», «Erejalde»), jefe 2 («Arteaga», 
«Benzoaga»), jefe 2 («Benzoaga», «Erejalde»)} 

Considérese la expresión jefe , - jefe 2 - El resultado 
de la expresión /, anterior es («Benzoaga»,«Erejalde»), 
mientras que el resultado de la expresión / 2 es la rela¬ 
ción vacía. Se cumple que f C / 2 ; según la definición, 
la expresión no es monótona. Las expresiones que se 
definen utilizando el operador de agrupación del álge¬ 
bra relacional extendida tampoco son monótonas. 

La técnica del punto fijo no funciona en vistas recur¬ 
sivas definidas con expresiones no monótonas. Sin 
embargo, existen situaciones en las que este tipo de vis¬ 
tas son útiles, en particular, para la definición de agre¬ 


gaciones en relaciones parte-subparte. Las relaciones 
de este tipo definen las subpartes que forman cada par¬ 
te. Las subpartes pueden estar formadas a su vez por 
muchas subpartes y así sucesivamente; por tanto, las 
relaciones, como la relación jefe, tiene una estructura 
recursiva por naturaleza. Un ejemplo de una consulta 
de agregación sobre tal estructura sería calcular el núme¬ 
ro total de subpartes de cada parte. Escribir esta con¬ 
sulta en Datalog o en SQL (sin extensiones procedi- 
mentales) requeriría el uso de una vista recursiva sobre 
una expresión no monótona. Las notas bibliográficas 
contienen referencias sobre la investigación sobre la 
definición de vistas de este tipo. 

Es posible definir algunos tipos de consultas recur¬ 
sivas sin utilizar vistas. Por ejemplo, se han propuesto 
operaciones relaciónales extendidas para definir el cie¬ 
rre transitivo, y extensiones de la sintaxis SQL para espe¬ 
cificar el cierre transitivo (generalizado). Sin embargo, 
las definiciones de vistas recursivas proporcionan una 
mayor potencia expresiva que las demás formas de con¬ 
sultas recursivas. 


5.3. INTERFACES DE USUARIO Y HERRAMIENTAS 


Aunque muchas personas interactúan con las bases de 
datos, pocas usan un lenguaje de consulta para interac¬ 
tuar directamente con un sistema de bases de datos. La 
mayoría interactúan mediante uno de los siguientes 
medios: 

1. Los formularios e interfaces gráficas de usua¬ 
rio permiten a los usuarios introducir valores 
que completan las consultas predefinidas. El sis¬ 
tema ejecuta las consultas y da formato apro¬ 
piado y muestra los resultados al usuario. Las 
interfaces gráficas de usuario proporcionan una 
forma fácil de interactuar con el sistema de bases 
de datos. 

2. Los generadores de informes permiten generar 
informes predefinidos sobre los contenidos actua¬ 
les de la base de datos. Los analistas o gestores 
examinan estos informes para tomar decisiones 
de negocio. 

3. Las herramientas de análisis de datos permi¬ 
ten a los usuarios examinar interactivamente y 
analizar los datos. 

Hay que hacer notar que estas interfaces usan len¬ 
guajes de consulta para comunicarse con los sistemas 
de bases de datos. 

En este apartado se proporciona una visión general 
de los formularios, interfaces gráficas de usuario y 
generadores de informes. El Capítulo 22 cubre las 
herramientas de análisis de datos con más detalle. Por 


desgracia no hay normas para las interfaces de usua¬ 
rio, y cada sistema de base de datos proporciona usual¬ 
mente su propia interfaz de usuario. En este apartado 
se describen los conceptos básicos, sin profundizar en 
los detalles de ningún producto en concreto. 

5.3.1. Formularios e interfaces gráficas 
de usuario 

Las interfaces de formularios se usan ampliamente para 
introducir y extraer datos en las bases de datos median¬ 
te consultas predefinidas. Por ejemplo, los motores 
World Wide Web proporcionan formularios que se usan 
para introducir palabras clave. Al pulsar el botón 
«Enviar» se provoca que el motor de búsqueda ejecute 
una consulta usando las palabras clave introducidas y 
que muestre el resultado al usuario. 

Como otro ejemplo más orientado a las bases de 
datos, es posible conectarse a un sistema de matrícula 
de una universidad, donde se pide que se rellene un 
código y una contraseña en un formulario. El sistema 
usa esta información para comprobar la identidad, así 
como para extraer de la base de datos información, como 
el nombre y las asignaturas en las que el alumno se ha 
matriculado, y mostrarla. Puede haber más vínculos en 
la página Web que permitan buscar asignaturas y encon¬ 
trar más información acerca de las asignaturas como el 
programa y el profesor. 

Los exploradores Web compatibles con HTML cons¬ 
tituyen los formularios e interfaces gráficas de usuario 
más ampliamente usados actualmente. La mayoría de 
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fabricantes de sistemas de bases de datos también pro¬ 
porcionan interfaces de formularios propietarias que 
ofrecen características más allá de las incluidas en los 
formularios HTML. 

Los programadores pueden crear formularios e inter¬ 
faces gráficas de usuario usando HTML o lenguajes de 
programación tales como C o Java. La mayoría de fabri¬ 
cantes de sistemas de bases de datos también propor¬ 
cionan herramientas que simplifican la creación de for¬ 
mularios de una forma declarativa sencilla, usando 
programas de edición de formularios. Los usuarios pue¬ 
den definir el tipo, tamaño y el formato de cada campo 
de un formulario usando el editor de formularios. Las 
acciones del sistema se pueden asociar con las acciones 
de los usuarios, como rellenar un campo, pulsar una 
tecla de función en el teclado o enviar un formulario. 
Por ejemplo, la ejecución de una consulta para rellenar 
los campos de nombre y dirección se pueden asociar 
con rellenar un campo de código, y la ejecución de una 
instrucción de actualización se puede asociar con el 
envío de un formulario. 

Se pueden realizar comprobaciones de errores sen¬ 
cillas definiendo restricciones sobre los campos del for¬ 
mulario 2 . Por ejemplo, una restricción sobre el campo 
número de asignatura podría comprobar que el núme¬ 
ro de asignatura escrito por el usuario corresponde real¬ 
mente con una asignatura. Aunque estas restricciones 
se pueden comprobar cuando se ejecuta la transacción, 
la detección temprana de errores ayuda a los usuarios 
a corregir rápidamente los errores. Los menús que indi¬ 
can los valores válidos que se pueden escribir en un 
campo pueden eliminar la posibilidad de muchos tipos 
de errores. Los desarrolladores de sistemas encuentran 
que su trabajo es mucho más fácil con la posibilidad 
de controlar tales características de forma declarativa 
la ayuda de una herramienta de desarrollo de interfa¬ 
ces de usuario, en lugar de crear el formulario directa¬ 
mente usando un lenguaje de guiones o de programa¬ 
ción. 

5.3.2. Generadores de informes 

Los generadores de informes son herramientas que gene¬ 
ran informes de resumen legibles de una base de datos. 
Integran la consulta a la base de datos con la creación 
de texto con formato y gráficos de resumen (tales como 
gráficos de barras o de tarta). Por ejemplo, un informe 


2 En Oracle se denominan «disparadores de formulario», pero en este 
libro se usará el término «disparador» con un sentido diferente que 
se estudia en el Capítulo 6. 


podría mostrar las ventas totales de los dos meses ante¬ 
riores para cada zona de ventas. 

El desarrollador de aplicaciones puede especificar 
formatos de informes usando las características de for¬ 
mato del generador de informes. Se pueden usar varia¬ 
bles para almacenar parámetros tales como el mes y el 
año y para definir campos del informe. Se pueden defi¬ 
nir tablas, gráficas de barras, gráficas de tarta u otros 
gráficos mediante consultas sobre la base de datos. Las 
definiciones de las consultas pueden usar valores de 
parámetros almacenados en las variables. 

Una vez que se ha definido la estructura del informe 
con un generador de informes, se puede almacenar y 
ejecutar cada vez que se genere un informe. Los siste¬ 
mas generadores de informes proporcionan varias carac¬ 
terísticas para estructurar una salida tabular, tal como 
definir las cabeceras de tabla y columna, mostrar sub¬ 
totales por cada grupo en una tabla, dividir automáti¬ 
camente una tabla grande en varias páginas y mostrar 
subtotales al final de cada página. 

La Figura 5.13 es un ejemplo de un informe con for¬ 
mato. Los datos del informe se generan por agregación 
de la información sobre los pedidos. 

La colección de herramientas de desarrollo de apli¬ 
caciones proporcionadas por los sistemas de bases de 
datos tales como los paquetes de formularios y los gene¬ 
radores de informes se conocen como lenguajes de cuar¬ 
ta generación (L4G). El nombre resalta que estas herra¬ 
mientas ofrecen un paradigma de la programación 
diferente del paradigma de programación imperativa 
ofrecido por los lenguajes de tercera generación como 
Pascal y C. Sin embargo, este término es menos relevante 
actualmente, dado que los formularios y los generado¬ 
res de informes se crean normalmente con herramientas 
gráficas en lugar de con lenguajes de programación. 


Compañía de Suministros Acmé S. A. 
Informe trimestral de ventas 

Período: 1 de enero a 31 de marzo de 2001 


Región 

Categoría 

Ventas 

Subtotal 

Norte 

Hardware 

1.000.000 

1.500.000 

Software 

500.000 

Todas las categorías 


Sur 

Hardware 

200.000 



Software 

400.000 



Todas las categorías 


600.000 


Ventas totales 2.100.000 


FIGURA 5.13. Informe con formato. 
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RESUMEN 


• Se han estudiado dos lenguajes de consulta: QBE y 
Datalog. 

• QBE está basado en un paradigma visual: las con¬ 
sultas son muy similares a tablas. 

• QBE y sus variantes se han hecho populares entre los 
usuarios poco expertos de base de datos, debido a la 
simplicidad intuitiva del paradigma visual. El siste¬ 
ma de bases de datos Access de Microsoft amplia¬ 
mente usado soporta una versión gráfica de QBE 
denominada GQBE. 

• Datalog se deriva de Prolog, pero a diferencia de éste, 
tiene una semántica declarativa que hace que las con¬ 
sultas sencillas sean más fáciles de formular y que la 
evaluación de consultas sea más fácil de optimizar. 


• Caja de condición 

• Cierre transitivo 

• Cuadrícula de diseño 

• Datalog 

• Definición de vistas monótonas 

• Depende 

— Directamente 
— Indirectamente 

• Ejemplares 

— Ejemplar básico 
— Satisfacer 

• Filas ejemplo 

• Formularios 

• Generadores de informes 

• Graphical Query-by-Example (GQBE, consulta grá¬ 
fica mediante ejemplos) 

• Hecho 

• Inferir 

• Interfaces gráficas de usuario 


• La definición de vistas es particularmente sencilla en 
Datalog y las vistas recursivas que permite Datalog 
hacen posible la formulación de consultas, tales como 
el cierre transitivo, que no podrían formularse sin uti¬ 
lizar recursividad o iteración. Sin embargo, en Data¬ 
log no existen normas para características importan¬ 
tes, como la agrupación y la agregación. Datalog sigue 
siendo principalmente un lenguaje de investigación. 

• La mayoría de los usuarios interactüan con las bases 
de datos mediante formularios e interfaces gráficas 
de usuario, y hay muchas herramientas para simpli¬ 
ficar la construcción de estas interfaces. Los genera¬ 
dores de informes son herramientas que ayudan a crear 
informes legibles a partir de los contenidos de la base 
de datos. 


• Literal negativo 

• Literal positivo 

• Microsoft Access 

• Programa Datalog 

• Punto fijo 

• Query-by-Example (QBE, consulta mediante ejemplos) 

• Regla 

— Cabeza 
— Cuerpo 

• Reglas 

• Relación resultado 

• Seguridad 

• Semántica 

— De una regla 
— De un programa 

• Sintaxis en dos dimensiones 

• Tablas esqueleto 

• Vista no recursiva 

• Vista recursiva 


TÉRMINOS DE REPASO 


EJERCICIOS 


5.1. Considérese la base de datos de seguros de la Figura 
5.14, donde las claves primarias se identifican porque 
empiezan por letra mayúscula. Formúlense las siguien¬ 
tes consultas en QBE: 

a. Buscar el número total de las personas cuyos coches 
se han visto involucrados en un accidente en 1989. 


b. Buscar el número de accidentes en los cuales se ha 
visto involucrado un coche perteneciente a «San¬ 
tos». 

c. Añadir un nuevo accidente a la base de datos; supón¬ 
gase cualquier valor para los atributos necesarios. 

d. Borrar el Mazda de «Santos». 
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persona ( id-conductor . nombre, dirección) 
coche ( matrícula , año, modelo) 
accidente ( número-informe , fecha , lugar) 
es-dueño ( id-conductor , matrícula ) 

participó ( id-conductor, coche, número-informe, importe-daños) 
FIGURA 5.14. Base de datos de seguros. 


e. Actualizar el importe de daños del coche de matrí¬ 
cula «2002BCD» en el accidente con número de 
informe «AR2197» a 3.000 €. 

5.2. Considérese la base de datos de empleados de la Figu¬ 
ra 5.15. Proporciónense expresiones en QBE y Data- 
log para cada una de las consultas siguientes: 

a. Buscar los nombres de todos los empleados que tra¬ 
bajan en el Banco Importante. 

b. Buscar los nombres y ciudades de residencia de 
todos los empleados que trabajan en el Banco Impor¬ 
tante. 

c. Buscar los nombres, direcciones y ciudades de resi¬ 
dencia de todos los empleados que trabajan en el 
Banco Importante y que ganan más de 10.000 €. 

d. Buscar todos los empleados que viven en la ciudad 
de la empresa para la que trabajan. 

e. Buscar todos los empleados que viven en la misma 
ciudad y en la misma calle que sus jefes. 

f. Buscar todos los empleados que no trabajan en el 
Banco Importante. 

g. Buscar todos los empleados que ganan más que cual¬ 
quier empleado del Banco Pequeño. 

h. Supóngase que las empresas pueden tener sede en 
varias ciudades. Buscar todas las empresas con sede 
en todas las ciudades en las que tiene sede el Ban¬ 
co Pequeño. 

5.3. Considérese la base de datos relacional de la Figura 

5.15, donde se han subrayado las claves primarias. Pro¬ 
porciónense expresiones en QBE y para cada una de 
las siguientes consultas: 

a. Buscar todos los empleados que ganan más que el 
sueldo medio de los empleados de su empresa. 

b. Buscar la empresa que tiene el mayor número de 
empleados. 

c. Buscar la empresa que tiene el menor sueldo medio. 

d. Buscar aquellas empresas cuyos empleados ganan 
un sueldo más alto, en media, que el sueldo medio 
del Banco Importante. 

5.4. Considérese la base de datos relacional de la Figura 

5.15. Proporciónense expresiones en QBE para cada 
una de las siguientes consultas: 

a. Modificar la base de datos para que «Santos » viva 
en Tres Cantos. 


empleado ( nombre-empleado , calle, ciudad) 
trabaja ( nombre-empleado , nombre-empresa, sueldo) 
empresa ( nombre-empresa , ciudad) 
jefe ( nombre-empleado , nombre-jefe) 

FIGURA 5.15. Base de datos de empleados. 


b. Dar un 10% de aumento de suelto a todos los em¬ 
pleados del Banco Importante. 

c. Dar un 10% de aumento de sueldo a todos los jefes 
de la base de datos. 

d. Dar un 10% de aumento de sueldo a todos los jefes 
de la base de datos, a menos que su sueldo esté por 
encima de 100.000 € anuales. En tal caso, darles 
solamente un 3%. 

e. Borrar todas las tupias de la relación trabaja para 
los empleados del Banco Pequeño. 

5.5. Sean los siguientes esquemas de relación: 

R = (A, B, C ) 

5 = (D, E, F) 

Sean las relaciones r (R) y s(S). Proporciónense expre¬ 
siones en QBE y Datalog equivalentes a cada una de 
las consultas siguientes: 

a. n A (r) 
b- o B = n (Y) 
c. r x s 

d- n v (ff c = fl (rxj)) 

5.6. Sea R - (A, B, C) y sean r, y r 2 relaciones del esquema 
R. Proporciónense expresiones en QBE y Datalog equi¬ 
valentes a cada una de las consultas siguientes: 

a. r , U r 2 

b. r, Cl r 2 

c. r¡ - r 2 

d- n Afi (r,) M II flc (r 2 ) 

5.7. Sean R = (A, B. C) y S = (A, C), y sean r (R) y s (S) rela¬ 
ciones. Escríbanse expresiones en QBE y Datalog para 
cada una de las siguientes consultas: 

a. {< a > I 3 b (< a, b > E r a b = 17)} 

b. {< a, b, c > I < a, b > E r a < a, c > E s} 

C. {< a > I 3 c (< a, c > E s a 3 b¡, b 2 (< a, b¡ > E r a < c, 
b 2 >Er a b¡> b 2 ))} 

5.8. Considérese la base de datos relacional de la Figura 
5.12. Escríbase un programa Datalog para cada una de 
las siguientes consultas: 

a. Buscar todos los empleados que trabajan (directa o 
indirectamente) bajo la dirección de «Santos». 

b. Buscar las ciudades de residencia de todos los em¬ 
pleados que trabajan (directa o indirectamente) bajo 
la dirección de «Santos». 

c. Buscar todas las parejas de empleados que tienen 
un jefe (directo o indirecto) en común. 

d. Buscar todas las parejas de empleados que tienen 
un jefe (directo o indirecto) en común y que están 
el mismo número de niveles bajo el jefe. 

5.9. Escríbase una vista del álgebra relacional extendida 
equivalente a la regla Datalog 

p(A, C, D) ql (A, B), q2 (B, C), 
q3 (4. B),D = B+ 1 

5.10. Descríbase cómo una regla de Datalog arbitraria pue¬ 
de expresarse como una vista del álgebra relacional 
extendida. 
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NOTAS BIBLIOGRÁFICAS 


La versión experimental de Query-by-Example se des¬ 
cribe en Zloof [1977]; la versión comercial se describe 
en IBM [1978b]. Muchos sistemas de bases de datos 
—en concreto, sistemas de bases de datos que se eje¬ 
cutan en computadoras personales— implementan QBE 
o variantes. Access de Microsoft y Paradox de Borland 
son ejemplos de ello. 

Algunas implementaciones de Datalog son el siste¬ 
ma LDL (descrito en Tsur y Zaniolo [1986] y Navqi y 
Tsur [1988]), Nail! (descrito en Derr et al. [1993]) y 
Coral (descrito en Ramakrishnan et al. [1992b] y en 
Ramakrishnan et al. [1993]). Las primeras discusiones 
sobre bases de datos lógicas se presentaron en Gallaire 
y Minker [1978] y en Gallaire et al. [1984]. Ullman 
[1988] y Ullman [1989] proporciona discusiones exten¬ 


sas de lenguajes lógicos de consulta y de técnicas de 
implementación. Ramakrishnan y Ullman [1995] pro¬ 
porcionan una visión de conjunto más reciente sobre 
bases de datos deductivas. 

A los programas Datalog que tienen tanto recursivi- 
dad como negación se les puede asignar una semántica 
sencilla si se «estratifica» la negación, es decir, si no 
hay recursividad durante la negación. La negación estra¬ 
tificada se discute en Chandra y Harel [1982] y en Apt 
y Pugin [1987]. Una extensión importante, llamada 
semántica de estratificación modular, que maneja una 
clase de programas recursivos con literales negativos, 
se discute en Ross [1990]; en Ramakrishnan et al. 
[1992c] se describe una técnica de evaluación para tales 
programas. 


HERRAMIENTAS 


QBE de Access de Microsoft es probablemente la imple- 
mentación de QBE más ampliamente usada. QMF de 
DB2 de IBM y Paradox de Borland también incluyen 
QBE. 

El sistema Coral de la Universidad de Wisconsin - 
Madison es una implementación de Datalog amplia¬ 


mente usada (véase http://www.cs.wisc.edu/coral). El 
sistema XSB de la Universidad estatal de Nueva York 
(SUNY) Stony Brook (http://xsb.sourceforge.net) es 
una implementación de Prolog ampliamente usada que 
soporta consultas a bases de datos; recuérdese que Data¬ 
log es un subconjunto no procedimental de Prolog. 
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CAPÍTULO 



INTEGRIDAD Y SEGURIDAD 


L as restricciones de integridad proporcionan un medio de asegurar que las modificacio¬ 
nes hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de 
la consistencia de los datos. Por tanto, las restricciones de integridad protegen a la base 
de datos contra los daños accidentales. 

En el Capítulo 2 ya se ha visto una modalidad de restricciones de integridad para el mode¬ 
lo E-R. Estas restricciones eran de los tipos siguientes: 


• Declaración de claves - la estipulación de que ciertos atributos pueden formar una clave 
para un conjunto de entidades determinado. 

• Forma de la relación - de varios a varios, de uno a varios, de uno a uno. 


En general, la restricción de integridad puede ser un predicado arbitrario referente a la base 
de datos. Sin embargo, los predicados arbitrarios pueden resultar complicados de verificar. En 
consecuencia, lo habitual es limitarse a restricciones de integridad que puedan verificarse con 
una sobrecarga mínima. En los apartados 6.1 y 6.2 se estudian estas formas de restricciones de 
integridad y una forma más compleja en el Apartado 6.3. En el Capítulo 7 se estudia otra for¬ 
ma de restricción de integridad, denominada «dependencia funcional», que se usa principal¬ 
mente en el proceso del diseño de esquemas. 

En el Apartado 6.4 se estudian los disparadores, que son instrucciones que el sistema eje¬ 
cuta automáticamente como efecto colateral de una modificación de la base de datos. Los dis¬ 
paradores se usan para asegurar algunos tipos de integridad. 

Además de la protección contra la introducción accidental de inconsistencia, puede ser nece¬ 
sario proteger los datos almacenados en la base de datos frente a accesos no autorizados y des¬ 
trucción o alteración malintencionada. En los apartados 6.5 hasta el 6.7 se examinan formas en 
que se puede hacer un mal uso de los datos o hacerlos intencionadamente inconsistentes, y se 
presentan mecanismos de seguridad para protegerse contra ello. 


6.1. RESTRICCIONES DE LOS DOMINIOS 


Se ha visto que hay que asociar a cada atributo un domi¬ 
nio de valores posibles. En el Capítulo 4 se vieron varios 
tipos de dominios estándar, tales como los enteros, carac¬ 
teres y fecha/tiempo en SQL. La declaración de que un 
atributo pertenezca a un determinado dominio actúa 
como una restricción sobre los valores que puede tomar. 
Las restricciones de los dominios son la forma más sim¬ 
ple de restricción de integridad. El sistema las verifica 
fácilmente siempre que se introduce en la base de datos 
un nuevo elemento de datos. 

Es posible que varios atributos tengan el mismo 
dominio. Por ejemplo, los atributos nombre-cliente y 
nombre-empleado pueden tener el mismo dominio: el 
conjunto de los nombres de persona. Sin embargo, los 
dominios de saldo y de nombre de la sucursal deben 
ser, ciertamente, diferentes. Quizá resulte menos evi¬ 
dente si nombre-cliente y nombre-sucursal deben tener 
el mismo dominio. En el nivel de implementación, 
tanto los nombres de los clientes como los de las 


sucursales son cadenas de caracteres. Sin embargo, 
normalmente no se considerará que la consulta «Hallar 
todos los clientes que tengan el nombre de una su¬ 
cursal» tenga sentido. Por tanto, si se considera la base 
de datos desde el punto de vista teórico, en vez 
de hacerlo desde el punto de vista físico, nombre- 
cliente y nombre-sucursal deben tener dominios di¬ 
ferentes. 

De la discusión anterior se puede deducir que una 
definición adecuada de las restricciones de los domi¬ 
nios no sólo permite verificar los valores introduci¬ 
dos en la base de datos, sino también examinar las 
consultas para asegurarse de que tengan sentido las 
comparaciones que hagan. El principio subyacente a 
los dominios de los atributos es parecido al de los tipos 
de las variables en los lenguajes de programación. Los 
lenguajes de programación con tipos estrictos per¬ 
miten al compilador examinar el programa con mayor 
detalle. 
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La cláusula create domain se puede usar para defi¬ 
nir nuevos dominios. Por ejemplo, las instrucciones: 

create domain Euros numeric(12,2) 
create domain Dólares numeric(12,2) 

definen los dominios Euros y Dólares como números 
decimales con un total de 12 dígitos, dos de los cuales 
se sitúan después de la coma decimal. Un intento de 
asignar un valor de tipo Dólares a una variable de tipo 
Euros resultaría en un error sintáctico, aunque ambos 
tengan el mismo tipo numérico. Tal asignación proba¬ 
blemente es debida a un error del programador, en el 
que este olvidó las diferencias de cambio. La declara¬ 
ción de diferentes dominios para diferentes monedas 
ayuda a detectar errores. 

Los valores de un dominio pueden ser convertidos a 
otro dominio. Si el atributo A de la relación r es de tipo 
Euros, se puede convertir a Dólares escribiendo: 

cast r.A as Dólares 

En una aplicación real se multiplicaría r.A por el factor 
de cambio antes de convertirlo a dólares. SQL también 
proporciona las cláusulas drop domain y alter domain 
para borrar o modificar dominios que se hayan decla¬ 
rado anteriormente. 

La cláusula check de SQL permite restringir los 
dominios de maneras poderosas que no permiten la 
mayor parte de los sistemas de tipos de los lenguajes de 
programación. Concretamente, la cláusula check per¬ 
mite al diseñador del esquema especificar un predica¬ 
do que debe satisfacer cualquier valor asignado a una 
variable cuyo tipo sea el dominio. Por ejemplo, una cláu¬ 
sula check puede asegurar que un dominio de sueldo 
por hora sólo permita valores mayores que un valor espe¬ 
cificado (como puede ser el sueldo mínimo), tal y como 
se muestra aquí: 

create domain sueldo-por-hora numeric(5,2) 
constraint comprobación-valor-sueldo 

check(value > 4.00) 

El dominio sueldo-por-hora tiene una restricción que 
asegura que el sueldo por hora sea mayor que 4,00. 
La orden constraint comprobación-valor-sueldo es 
opcional y se utiliza para dar a la restricción el nom¬ 


bre de comprobación-valor-sueldo. El nombre se uti¬ 
liza para indicar la restricción violada por una actua¬ 
lización. 

La cláusula check también puede utilizarse para res¬ 
tringir un dominio para que no contenga valores nulos, 
como se muestra aquí: 

create domain número-cuenta char(10) 

constraint comprobación-número—cuenta-nulo 

check(value not nuil) 

En este otro ejemplo el dominio se puede limitar para 
que contenga sólo un conjunto especificado de valores 
usando la cláusula in: 

create domain tipo-cuenta char(10) 

constraint comprobación-tipo-cuenta 

check(valué in (‘Corriente’, ‘Ahorro’)) 

Las condiciones check anteriores se puede compro¬ 
bar muy fácilmente cuando se inserta o modifica una 
tupia. Sin embargo, en general, las condiciones check 
pueden ser muy complejas (y difíciles de comprobar) 
dado que se permiten subconsultas que se refieren a otras 
relaciones en la condición check. Por ejemplo, esta 
restricción se podría especificar sobre la relación prés¬ 
tamo : 

check (nombre-sucursal in 

(select nombre-sucursal from sucursal)) 

La condición check verifica que nombre-sucursal en 
cada tupia en la relación préstamo es realmente el nom¬ 
bre de una sucursal de la relación cuenta. Así, la con¬ 
dición no sólo se debe comprobar cuando se inserte o 
modifique préstamo, sino también cuando cambie la 
relación sucursal (en este caso, cuando se borre o modi¬ 
fique cuenta). 

La restricción anterior es realmente un ejemplo de 
una clase de restricciones denominadas restricciones de 
integridad referencia!. En el Apartado 6.2 se estudian 
estas restricciones y la forma de especificarlas de for¬ 
ma más sencilla en SQL. 

Las condiciones check complejas pueden ser útiles 
cuando se desee asegurar la integridad de los datos, pero 
se deben usar con cuidado, dado que pueden ser costo¬ 
sas de comprobar. 


6.2. INTEGRIDAD REFERENCIAL 


A menudo se desea asegurar que un valor que aparece 
en una relación para un conjunto de atributos determi¬ 
nado aparezca también en otra relación para un cierto 
conjunto de atributos. Esta condición se denomina inte¬ 
gridad referencial. 


6.2.1. Conceptos básicos 

Considérese un par de relaciones r (R) y s (S) y la reunión 
natural rMs. Puede haber una tupia t r de r que no se reú¬ 
na con ninguna tupia de 5. Es decir, no hay ningún t s en 5 
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tal que t r [S fl 5] = t s \R n S]. Estas tupias se denominan 
colgantes. Las tupias colgantes pueden ser aceptables en 
función del conjunto de entidades o de relaciones que se 
esté modelando. En el Apartado 3.5.2 se tomó en consi¬ 
deración una forma de reunión modificada —la reunión 
extema— para operar con las relaciones que contengan 
tupias colgantes. En este caso el motivo de preocupación 
no son las consultas, sino el momento en que se desea per¬ 
mitir que haya tupias colgantes en la base de datos. 

Supóngase que hay una tupia /j en la relación cuen¬ 
ta con i, [nombre-sucursal] = «As Pontes» pero que no 
hay ninguna tupia de la relación sucursal para la sucur¬ 
sal de As Pontes. Esta situación no es deseable. Se espe¬ 
ra que la relación sucursal muestre una relación de todas 
las sucursales bancarias. Por tanto, la tupia i, hará refe¬ 
rencia a una cuenta de una sucursal que no existe. Evi¬ 
dentemente, es preferible tener una restricción de inte¬ 
gridad que prohíba las tupias colgantes de este tipo. 

Sin embargo, algunos casos de tupias colgantes pue¬ 
den resultar convenientes. Supóngase que hay una tupia 
t 2 de la relación sucursal con t 2 [nombre-sucursal] = 
«Gijón» pero que no hay ninguna tupia de la relación 
cuenta para la sucursal de Gijón. En este caso hay una 
sucursal que no tiene ninguna cuenta. Aunque esta situa¬ 
ción no es frecuente, puede producirse cuando se abre 
una sucursal o cuando está a punto de cerrar. Por tanto, 
no es deseable prohibir esta situación. 

La distinción entre estos dos ejemplos se basa en dos 
hechos: 

• El atributo nombre-sucursal de Esquema-cuenta 
es una clave externa que hace referencia a la cla¬ 
ve primaria de Esquema-sucursal. 

• El atributo nombre-sucursal de Esquema-sucursal 
no es una clave externa. 

(Recuérdese del Apartado 3.1.3 que una clave externa 
es un conjunto de atributos del esquema de una relación 
que forma la clave primaria de otro esquema.) 

En el ejemplo de As Pontes la tupia t¡ de cuenta tie¬ 
ne un valor en la clave externa nombre-sucursal que no 
aparece en sucursal. En el ejemplo de la sucursal de 
Gijón, la tupia t 2 de sucursal tiene un valor de nombre- 
sucursal que no aparece en cuenta, pero nombre-sucur¬ 
sal no es una clave externa. Por tanto, la distinción entre 
los dos ejemplos de tupias colgantes es la presencia de 
una clave extema. 

Sean r^R,) y r 2 (R 2 ) dos relaciones con las claves pri¬ 
marias K { y K 2 , respectivamente. Se dice que un sub¬ 
conjunto a de R 2 es una clave externa que hace refe¬ 
rencia a Áj de la relación r, si se exige que para cada t 2 
de r 2 haya una tupia t x de r { tal que t { \K { \ = t 2 [a\. Las 
exigencias de este tipo se denominan restricciones de 
integridad referencial o dependencia de subconjun¬ 
to. El último término se debe a que esta última restric¬ 
ción de integridad referencial puede escribirse como El a 
(r 2 ) C U K¡ (/•,). Obsérvese que, para que una restricción 
de integridad referencial tenga sentido, a debe ser igual 


a R¡, o bien o. y K x deben ser conjuntos compatibles de 
atributos. 

6.2.2. Integridad referencial en el modelo E-R 

Las restricciones de integridad referencial aparecen con 
frecuencia. Si se obtiene el esquema de la base de datos 
relacional creando tablas a partir de los diagramas E-R, 
tal y como se vio en el Capítulo 2, cada relación que pro¬ 
ceda de un conjunto de relaciones tendrá restricciones 
de integridad referencial. En la Figura 6.1 se muestra un 
conjunto n-ario de relaciones R, que relaciona los con¬ 
juntos de entidades £j, E 2 ,..., E n . K¡ denota la clave pri¬ 
maria de E¡. Los atributos del esquema de la relación del 
conjunto de relaciones R incluyen K x U K 2 U ... U K n . 
Cada K¡ del esquema de R es una clave externa que lle¬ 
va a una restricción de integridad referencial. 

Otra fuente de restricciones de integridad referencial 
son los conjuntos de entidades débiles. Recuérdese del 
Capítulo 2 que el esquema de la relación de un conjun¬ 
to de entidades débiles debe incluir la clave primaria 
del conjunto de entidades del que este depende. Por tan¬ 
to, el esquema de la relación de cada conjunto de enti¬ 
dades débiles incluye una clave externa que lleva a una 
restricción de integridad referencial. 

6.2.3. Modificación de la base de datos 

La modificación de la base de datos puede ocasionar 
violaciones de la integridad referencial. A continuación 
se describe la comprobación que debe hacerse para cada 
tipo de modificación de la base de datos para preservar 
la siguiente restricción de integridad referencial: 

n a (/- 2 )cn*.(r,) 

• Insertar. Si se inserta una tupia f 2 en r 2 , el siste¬ 
ma debe asegurar que hay una tupia t x de r, tal que 
t { \K\ = ? 2 [a|. Es decir, 

t 2 [a\ G El* (/q) 



FIGURA 6.1. Un conjunto de relaciones N-ario. 
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• Borrar. Si se borra una tupia f, de r l el sistema 
debe calcular el conjunto de tupias de r 2 que hacen 
referencia a r x : 

°a = t x [K\ ( r l) 

Si este conjunto no es el conjunto vacío, o bien se 
rechaza la orden borrar como error, o bien se deben 
borrar las tupias que hacen referencia a t x . La últi¬ 
ma solución puede llevar a borrados en cascada, 
dado que las tupias pueden hacer referencia a tupias 
que hagan referencia a q, etcétera. 

• Actualizar. Hay que considerar dos casos: las 
actualizaciones de la relación que realiza la refe¬ 
rencia (r 2 ) y las actualizaciones de la relación a la 
que se hace referencia (r j). 

— Si se actualiza la tupia t 2 de la relación r 2 y esta 
actualización modifica valores de la clave exter¬ 
na a, se realiza una comprobación parecida a la 
del caso de la inserción. Si t' 2 denota el nuevo 
valor de la tupia f 2 , el sistema debe asegurar que 

f' 2 [cx] G (/-,) 

— Si se actualiza la tupia t ] de la relación r¡ y esta 
actualización modifica valores de la clave pri¬ 
maria ( K ), se realiza una comprobación pare¬ 
cida a la del caso del borrado. El sistema debe 
asegurar que 

°a = /,[£] O2) 

utilizando el valor anterior de /, (el valor antes 
de que se lleve a cabo la actualización). Si este 
conjunto no es el conjunto vacío, la actualiza¬ 
ción se rechaza como error o se ejecuta en cas¬ 
cada de manera parecida al borrado. 

6.2.4. Integridad referencial en SQL 

Las claves primarias pueden especificarse como parte 
de la instrucción create table de SQL usando la cláusu¬ 
la foreign key. Se ilustrarán las declaraciones de clave 
externa usando la definición del LDD de SQL de parte 
de la base de datos bancaria, mostrada en la Ligura 6.2. 

De manera predeterminada, una clave externa refe¬ 
rencia los atributos que forman la clave primaria de la 
tabla referenciada. SQL también soporta una versión de 
la cláusula references, donde se puede especificar explí¬ 
citamente una lista de atributos de la relación referen¬ 
ciada. Esta lista se debe declarar como clave candidata 
de la relación referenciada. 

Se puede usar la siguiente forma abreviada como 
parte de la definición de un atributo para declarar que 
el atributo forma una clave extema: 

nombre-sucursal char(15) references sucursal 

Cuando se viola una restricción de integridad refe¬ 
rencial, el procedimiento normal es rechazar la acción 


create table cliente 


(nombre-cliente 

char(20). 

calle-cliente 

char(30). 

ciudad-cliente 

char(30). 

primary key (nombre-cliente)) 

create table sucursal 


(nombre-sucursal 

char(15). 

ciudad-sucursal 

char(30). 

activo 

integer, 

primary key ( nombre-sucursal ), 

check (activo > = 0)) 


create table cuenta 


(número-cuenta 

char(10). 

nombre-sucursal 

char(15). 

saldo 

integer, 


primary key ( número-cuenta), 

foreign key ( nombre-sucursal) references sucursal, 

check (saldo >= 0)) 

create table impositor 

(nombre-cliente char(20), 

número-cuenta char(10), 

primary key ( nombre-cliente, número-cuenta), 
foreign key ( nombre-cliente) references cliente, 
foreign key ( número-cuenta) references cuenta) 

FIGURA 6.2. Definición en SQL de los datos de parte de la 
base de datos bancaria. 


que provocó la violación. Sin embargo, la cláusula 
foreign key puede especificar que si una acción de 
borrado o de actualización de la relación a la que hace 
referencia viola la restricción, en lugar de rechazar la 
acción, hay que adoptar medidas para modificar la tupia 
de la relación que hace la referencia con objeto de res¬ 
taurar la restricción. Considérese la siguiente definición 
de una restricción de integridad de la relación cuenta : 

create table cuenta 

(... _ 

foreign key (nombre-sucursal) references sucursal 

on delete Cascade 
on update Cascade, 

...) 

Debido a la cláusula on delete Cascade asociada con la 
declaración de la clave externa, si un borrado de una 
tupia de sucursal da lugar a que se viole la restricción 
de integridad referencial, el sistema no rechaza el borra¬ 
do. En su lugar, el borrado se realiza en «cascada» en la 
relación cuenta, borrando la tupia que hace referencia a 
la sucursal que se borró. De modo parecido, no se recha¬ 
za la actualización de un campo al que haga referencia 
la restricción si viola esta; en vez de eso, el campo nom¬ 
bre-sucursal de las tupias que realizan la referencia de 
cuenta se actualizan también al nuevo valor. SQL tam¬ 
bién permite que la cláusula foreign key especifique una 
acción diferente a Cascade si se viola la restricción: el 
campo que hace la referencia (en este caso, nombre- 
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sucursal) se puede establecer en nulo o darle un valor 
predeterminado para el dominio (usando set default). 

Si hay una cadena de dependencias de claves externas 
entre varias relaciones, un borrado o una actualización en 
uno de sus extremos puede propagarse por toda la cade¬ 
na. En el Ejercicio 6.4 se toma en consideración un caso 
interesante en el que la restricción foreign key de una 
relación hace referencia a esa misma relación. Si una 
actualización o borrado en cascada crea una violación de 
la restricción que no puede resolverse mediante una nue¬ 
va operación en cascada, el sistema aborta la transacción. 
En consecuencia, todas las modificaciones generadas por 
la transacción y por sus acciones en cascada se deshacen. 

En SQL la semántica de las claves se complica por 
el hecho de que SQL permite valores nulos. Los atri¬ 
butos de las claves externas pueden ser nulos, dado que 
no se han declarado como no nulos. Si todas las colum¬ 
nas de una clave externa contienen nulos para una tupia 
en concreto, se usa para esta tupia la definición usual 
de las restricciones de clave externa. Si alguna de las 
columnas contiene un valor nulo, la tupia se define auto¬ 
máticamente como que cumple la restricción. 

Puede que esta definición no sea siempre la mejor 
elección, así que SQL proporciona constructores que 


permiten cambiar el comportamiento con los valores 
nulos; aquí no se tratan estos constructores. Para evitar 
esta complejidad, es mejor asegurarse de que todas las 
columnas con especificaciones foreign key se declaren 
como no nulas. 

Las transacciones pueden consistir en varios pasos, y 
las restricciones de integridad se pueden violar tempo¬ 
ralmente después de un paso, pero en un paso posterior 
la violación puede desaparecer. Por ejemplo, supóngase 
que se tiene la relación personacasada con clave prima¬ 
ria nombre y un atributo cónyuge, y supónganse que cón¬ 
yuge es una clave extema de personacasada. Es decir, 
la restricción dice que el atributo cónyuge debe contener 
un nombre que aparezca en la tabla persona. Supónga¬ 
se que se desea añadir el hecho de que Juan y María están 
casados insertando dos tupias, una para Juan y otra para 
María en la relación anterior. La inserción de la primera 
tupia violaría la restricción de clave externa, indepen¬ 
dientemente de cuál de las dos tupias se haya insertado 
primero. Después de que se inserte la segunda tabla, la 
restricción de clave externa se volvería a cumplir. 

Para manejar estas situaciones las restricciones de 
integridad se comprueban al final de la transacción en 
lugar de en los pasos intermedios 1 . 


6.3. ASERTOS 


Un aserto es un predicado que expresa una condición 
que se desea que la base de datos satisfaga siempre. Las 
restricciones de dominio y las de integridad referencial 
son formas especiales de los asertos. Se ha prestado una 
atención especial a estos tipos de asertos porque se pue¬ 
den verificar con facilidad y se aplican a una gran varie¬ 
dad de aplicaciones de bases de datos. Sin embargo, hay 
muchas restricciones que no se pueden expresar utili¬ 
zando únicamente estas formas especiales. Ejemplos de 
estas restricciones pueden ser 

• La suma de todos los importes de los préstamos de 
cada sucursal debe ser menor que la suma de todos 
los saldos de las cuentas de esa sucursal. 

• Cada préstamo tiene al menos un cliente que tiene una 
cuenta con un saldo mínimo de 1.000 €. 

En SQL los asertos adoptan la forma 
create assertion <nombre-aserto> check <predicado> 

Las dos restricciones mencionadas pueden escribir¬ 
se tal y como se muestra a continuación. Dado que SQL 
no proporciona ningún mecanismo «para todo X, P(X )» 


1 El problema de este ejemplo se puede resolver de otra forma si el 
atributo cónyuge puede ser nulo: se ponen los atributos cónyuge a 
nulo al insertar las tupias de Juan y María, y se actualizan más tarde. 
Sin embargo, esta técnica no es aconsejable y no funciona si los atri¬ 
butos no pueden tomar el valor nulo. 


(donde P es un predicado), no queda más remedio que 
implementarlo utilizando su equivalente «no existe X 
tal que no P(X)», que puede escribirse en SQL. 

create assertion restricción-suma check 
(not exists (select * from sucursal 

where (select sum {importe) from préstamo 
where préstamo.nombre-sucursal 
= sucursal.nombre-sucursal) 

>= (select sum ( importe ) from cuenta 
where préstamo.nombre-sucursal 

= sucursal.nombre-sucursal))) 

create assertion restricción-saldo check 
(not exists (select * from préstamo 
where not exists (select * 

from prestatario, impositor, cuenta 
where préstamo.número-préstamo 

= prestatario.número-préstamo 
and prestatario.nombre-prestatario 
= impositor.nombre-cliente 
and impositor.número-cuenta 
= cuenta.número-cuenta 
and cuenta.saldo >= 1000))) 
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Cuando se crea un aserto el sistema comprueba su 
validez. Si el aserto es válido, sólo se permiten las modi¬ 
ficaciones posteriores de la base de datos que no hagan 
que se viole el aserto. Esta comprobación puede intro¬ 
ducir una sobrecarga importante si se han realizado aser¬ 
tos complejos. Por tanto, los asertos deben utilizarse 


con mucha cautela. La elevada sobrecarga debida a la 
comprobación y al mantenimiento de los asertos ha lle¬ 
vado a algunos desarrolladores de sistemas a soslayar 
el soporte para los asertos generales, o bien a propor¬ 
cionar formas especializadas de aserto que resultan más 
sencillas de verificar. 


6.4. DISPARADORES 


Un disparador es una orden que el sistema ejecuta de 
manera automática como efecto secundario de la modi¬ 
ficación de la base de datos. Para diseñar un mecanis¬ 
mo disparador hay que cumplir dos requisitos: 

1. Especificar las condiciones en las que se va a eje¬ 
cutar el disparador. Esto se descompone en un 
evento que causa la comprobación del disparador 
y una condición que se debe cumplir para ejecu¬ 
tar el disparador. 

2. Especificar las acciones que se van a realizar 
cuando se ejecute el disparador. 

Este modelo de disparadores se denomina modelo even- 
to-condición-acc¡ón. 

La base de datos almacena disparadores como si fue¬ 
sen datos normales, por lo que son persistentes y acce¬ 
sibles para todas las operaciones de la base de datos. 
Una vez se almacena un disparador en la base de datos, 
el sistema de base de datos asume la responsabilidad de 
ejecutarlo cada vez que ocurra el evento especificado y 
se satisfaga la condición correspondiente. 

6.4.1. Necesidad de los disparadores 

Los disparadores son mecanismos útiles para alertar a 
los usuarios o para realizar de manera automática cier¬ 
tas tareas cuando se cumplen determinadas condicio¬ 
nes. A modo de ejemplo supóngase que, en lugar de per¬ 
mitir saldos de cuenta negativos, el banco trata los 
descubiertos dejando a cero el saldo de las cuentas y 
creando un préstamo por el importe del descubierto. 
Este préstamo recibe un número de préstamo idéntico 
al número de cuenta que ha tenido el descubierto. En 
este ejemplo la condición para ejecutar el disparador es 
una actualización de la relación cuenta que dé lugar a 
un valor negativo de saldo. Supóngase que Santos reti¬ 
ró cierta cantidad de dinero de una cuenta que dio lugar 
a que el saldo de la cuenta fuera negativo, t denota la 
tupia de la cuenta con un valor negativo de saldo. Las 
acciones que hay que emprender son las siguientes: 

• Insertar una nueva tupia 5 a la relación préstamo con 

s[nombre-sucursal] = t[nombre-sucursal] 
s[número-préstamo] = t[número-cuenta ] 
s\importe] = - t[saldo ] 


(Obsérvese que, dado que t[saldo] es negativo, hay 
que cambiar el signo de t[saldo] para obtener el 
importe del préstamo - un número positivo). 

• Insertar una nueva tupia u a la relación prestata¬ 
rio con 

u[nombre-cliente] = «Santos» 
u[número-préstamo ] = t[número-cuenta] 

• Hacer que t[saldo] sea 0. 

Como otro ejemplo del uso de disparadores, supón¬ 
gase un almacén que desee mantener un inventario míni¬ 
mo de cada producto; cuando el nivel de inventario de 
un producto cae por debajo del nivel mínimo, se debe¬ 
ría solicitar un pedido automáticamente. Para imple- 
mentar con disparadores esta regla de negocio se haría: 
al modificar el nivel de inventario de un producto, el 
disparador debería comparar el nivel con el mínimo y 
si el nivel es inferior al mínimo, se añadiría un nuevo 
pedido a la relación pedido. 

Obsérvese que los sistemas de disparadores en gene¬ 
ral no pueden realizar actualizaciones fuera de la base 
de datos, y por lo tanto, en este último ejemplo, no se 
puede usar un disparador para realizar un pedido en el 
mundo extemo. En su lugar se añade un pedido a la rela¬ 
ción pedidos como en el ejemplo del inventario. Se debe 
crear un proceso del sistema separado que se esté eje¬ 
cutando constantemente que explore periódicamente la 
relación pedidos y solicite los pedidos. Este proceso del 
sistema anotaría las tupias de la relación pedidos que se 
han procesado y cuándo se ha procesado cada pedido. 
El proceso también llevaría cuenta del despacho de pedi¬ 
dos y alertaría a los gestores en caso de condiciones 
excepcionales tales como retrasos en las entregas. 

6.4.2. Disparadores en SQL 

Los sistemas de bases de datos SQL usan ampliamente 
los disparadores, aunque antes de SQL: 1999 no fueron 
parte de la norma. Por desgracia, cada sistema de bases 
de datos implemento su propia sintaxis para los dispa¬ 
radores, conduciendo a incompatibilidades. En la Figu¬ 
ra 6.3 se describe la sintaxis SQL: 1999 para los dispa¬ 
radores (que es similar a la sintaxis de los sistemas de 
bases de datos DB2 de IBM y de Oracle). 


146 



CAPÍTULO 6 


INTEGRIDAD Y SEGURIDAD 


create trigger descubierto after update on cuenta 
referencing new row as nfíla 
for each row 
when nfíla.saldo < 0 

begin atomic 

insert into prestatario 

(select nombre-cliente, número-cuenta 
from impositor 

where nfíla.número-cuenta = impositor.número-cuenta ); 

insert into préstamo valúes 

(nfíla.número-cuenta, nfíla.nombre-sucursal, - nfíla.saldo) 
update cuenta set saldo = 0 

where cuenta.número-cuenta = nfíla.número-cuenta 

end 

FIGURA 6.3. Ejemplo de la sintaxis de SQL1999 para los disparadores. 


Esta definición de disparador especifica que el dispa¬ 
rador se inicia después (after) de cualquier actualización 
de la relación cuenta. Una instrucción de actualización 
SQL podría actualizar múltiples tupias de la relación, y 
la cláusula for each row en el código del disparador se 
iteraría explícitamente por cada fila actualizada. La cláu¬ 
sula referencing new row as crea una variable nfila 
(denominada variable de transición) que almacena el 
valor de una fila actualizada después de la actualización. 

La instrucción when especifica una condición, en 
este caso nfila.sal do < 0. El sistema ejecuta el resto del 
cuerpo del disparador sólo para las tupias que satisfa¬ 
cen la condición. La cláusula begin atomic ... end sir¬ 
ve para encuadrar varias instrucciones SQL en una úni¬ 
ca instrucción compuesta. Las dos instrucciones in s ert 
en la estructura begin ... end realizan las tareas espe¬ 
cíficas para la creación de nuevas tupias en las relacio¬ 
nes prestatario y préstamo para representar el nuevo 
préstamo. La instrucción update sirve para establecer 
en 0 el saldo de la cuenta. 

El evento del disparador puede tener varias formas: 

• El evento del disparador puede ser insert o dele- 
te en lugar de update. 

Por ejemplo, la acción sobre el borrado (dele- 
te) de una cuenta podría comprobar si los tenedo¬ 
res de la cuenta tienen otras cuentas y, si no las tie¬ 
nen, borrarlas de la relación impositor. Se deja al 
lector la definición de este disparador como ejer¬ 
cicio (Ejercicio 6.7). 

Como otro ejemplo, si se inserta un nuevo impo¬ 
sitor, la acción del disparador podría ser enviar una 
carta de bienvenida al impositor. Obviamente, un 
disparador no puede causar directamente esta acción 
fuera de la base de datos, pero en su lugar sí pue¬ 
de insertar una nueva tupia a una relación que alma¬ 
cene las direcciones a las que se deben enviar las 
cartas de bienvenida. Un proceso separado exami¬ 
naría esta relación e imprimiría las cartas a enviar. 

• Para las actualizaciones el disparador puede espe¬ 
cificar columnas cuya actualización cause la eje¬ 
cución del disparador. Por ejemplo, si la primera 


línea del disparador de descubiertos se reempla¬ 
zase por 

create trigger descubierto after update of 

saldo on cuenta 

entonces el disparador se ejecutaría sólo cuando 
se actualizase saldo; las actualizaciones del resto 
de atributos no causarían su ejecución. 

• La cláusula referencing oíd row as se puede usar 
para crear una variable que almacene el valor ante¬ 
rior de una fila actualizada o borrada. La cláusula 
referencing new row as se puede usar con las 
inserciones además de las actualizaciones. 

• Los disparadores se pueden activar antes (before) 
del evento (¡nsert/delete/update) en lugar de des¬ 
pués (after) del evento. 

Estos disparadores pueden servir como restric¬ 
ciones extras que pueden evitar actualizaciones no 
válidas. Por ejemplo, si no se desea permitir des¬ 
cubiertos, se puede crear un disparador before que 
retroceda la transacción si el nuevo saldo es nega¬ 
tivo. 

Como otro ejemplo, supóngase que el valor del 
campo de número telefónico de una tupia insertada 
está vacío, que indica la ausencia de un número de 
teléfono. Se puede definir un disparador que reem¬ 
place el valor por el valor nuil. Se puede usar la ins¬ 
trucción set para realizar estas modificaciones. 

create trigger poner-nulo before update on r 
referencing new row as nfila 
for each row 

when nfila.número-teléfono = ' ' 
set nfila.número-teléfono = nuil 

• En lugar de realizar una acción por cada fila afec¬ 
tada, se puede realizar una acción única para la ins¬ 
trucción SQL completa que causó la inserción, 
borrado o actualización. Para hacerlo se usa la cláu¬ 
sula for each statement en lugar de for each row. 

Las cláusulas referencing oíd table as o refe¬ 
rencing new table as se pueden usar entonces para 
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hacer referencia a tablas temporales (denomina¬ 
das tablas de transición) conteniendo todas las filas 
afectadas. Las tablas de transición no se pueden 
usar con los disparadores before, pero sí con los 
after, independientemente de si son disparadores 
de instrucciones (statement) o de filas (row). 

Una instrucción SQL única se puede usar enton¬ 
ces para realizar varias acciones en términos de las 
tablas de transición. 

Volviendo al ejemplo de inventario del almacén, 
supóngase que se tienen las siguientes relaciones: 

• inventario (producto, nivel), que denota la canti¬ 
dad actual (número/peso/volumen) del producto 
en el almacén. 

• nivelmínimo(producto, nivel), que denota la can¬ 
tidad mínima a mantener de cada producto. 

• nuevopedido(producto, cantidad), que denota la 
cantidad de producto a pedir cuando su nivel cae 
por debajo del mínimo. 

• pedidosiproducto, cantidad), que denota la canti¬ 
dad de producto a pedir. 

Se puede usar entonces el disparador mostrado en la 
Figura 6.4 para solicitar un nuevo pedido del producto. 

Obsérvese que se ha sido cuidadoso a la hora de rea¬ 
lizar un pedido sólo cuando su cantidad caiga desde un 
nivel superior al mínimo a otro inferior. Si sólo se com¬ 
probase si el nuevo valor después de la actualización 
está por debajo del mínimo, se podría realizar errónea¬ 
mente un pedido cuando el producto ya se ha pedido. 

Muchos sistemas de bases de datos proporcionan 
implementaciones no estándar de disparadores, o imple- 
mentan sólo algunas de las características de los dispa¬ 
radores. Por ejemplo, muchos de los sistemas de bases 
de datos no implementan la cláusula before, y usan la 
palabra clave on en lugar de after. Puede que no imple- 
menten la cláusula referencing. En su lugar, pueden 
especificar tablas de transición usando las palabras cla¬ 
ve ¡nserted o deleted. La Figura 6.5 ilustra cómo se 


escribiría el disparador de los descubiertos de las cuen¬ 
tas en SQLServer de Microsoft. Consúltese el manual 
del sistema de bases de datos que se esté usando para 
obtener más información sobre las características de los 
disparadores que soporta. 

6.4.3. Cuándo no deben usarse 
los disparadores 

Hay muchos buenos usos de los disparadores, como los 
que se acaban de ver en el Apartado 6.4.2, pero algunos 
usos se manejan mejor con otras técnicas. Por ejemplo, 
anteriormente, los diseñadores de sistemas usaban los 
disparadores para realizar resúmenes de datos. Por ejem¬ 
plo, usaban disparadores bajo la inserción, borrado o 
actualización de una relación empleado que contiene 
los atributos sueldo y dept para mantener el sueldo total 
de cada departamento. Sin embargo, muchos sistemas 
de bases de datos actuales soportan las vistas materia¬ 
lizadas (véase el Apartado 3.5.1), que proporcionan una 
forma mucho más sencilla de mantener los datos de 
resumen. Los diseñadores también usaban ampliamen¬ 
te los disparadores para las réplicas de las bases de datos; 
usaban disparadores bajo la inserción, borrado o actua¬ 
lización de las relaciones para registrar los cambios en 
relaciones cambio o delta. Un proceso separado copia¬ 
ba los cambios a la réplica (copia) de la base de datos, 
y el sistema ejecutaba los cambios sobre la réplica. Sin 
embargo, los sistemas de bases de datos modernos pro¬ 
porcionan características incorporadas para la réplica 
de bases de datos, haciendo innecesarios a los dispara¬ 
dores para la réplica en la mayoría de los casos. 

De hecho, muchas aplicaciones de disparadores, 
incluyendo el ejemplo de descubiertos, se pueden sus¬ 
tituir por las características de «encapsulación» intro¬ 
ducidas en SQL: 1999. La encapsulación se puede usar 
para asegurar que las actualizaciones del atributo saldo 
de cuenta se hagan sólo mediante un procedimiento 
especial. Este procedimiento comprobaría un saldo nega¬ 
tivo y realizaría las acciones de disparador de descu¬ 
biertos. Las encapsulaciones pueden reemplazar el dis¬ 
parador de nuevos pedidos de forma similar. 


create trigger nuevopedido after update of cantidad on inventario 

referencing oíd row as ofila, new row as nfila 
for each row 

when nfila.nivel <= (select nivel 

from nivelmínimo 

where nivelmínimo.producto = ofila.producto) 
and ofila.nivel <= (select nivel 

from nivelmínimo 

where nivelmínimo.producto = ofila.producto) 

begin 

insert into pedidos 

(select producto, cantidad 
from nuevopedido 

where nuevopedido.producto= ofila.producto); 

end 

FIGURA 6.4. Ejemplo de un disparador para hacer un nuevo pedido de un producto. 
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define trigger descubierto on cuenta 

for update 
as 

¡f nfila.saldo < 0 

begin 

insert into prestatario 

(select nombre-cliente, número-cuenta 
from impositor, inserted 

where inserted. número-cuenta = ¡mpositor.número-cuenta) 

insert into préstamo valúes 

(inserted. número-cuenta, inserted. nombre-sucursal, - inserted. saldo) 
update cuenta set saldo = 0 
from cuenta, inserted 

where cuenta.número-cuenta = inserted. número-cuenta)) 

end 

FIGURA 6.5. Ejemplo de disparador en la sintaxis de SQLServer de Microsoft. 


Los disparadores se deberían escribir con sumo cui¬ 
dado, dado que un error de un disparador detectado en 
tiempo de ejecución causa el fallo de la instrucción de 
inserción, borrado o actualización que inició el dispa¬ 
rador. En el peor de los casos esto podría dar lugar a una 
cadena infinita de disparos. Por ejemplo, supóngase que 
un disparador de inserción sobre una relación realice 
otra (nueva) inserción sobre la misma relación. La acción 
de inserción dispara otra acción de inserción, y así has¬ 
ta el infinito. Generalmente, los sistemas de bases de 
datos limitan la longitud de las cadenas de disparado¬ 


res (por ejemplo, hasta 16 o 32), y consideran que las 
cadenas mayores son erróneas. 

Los disparadores (desencadenadores en terminolo¬ 
gía de Microsoft) se denominan a veces reglas o reglas 
activas, pero no se deben confundir con las reglas Data- 
log (véase el Apartado 5.2), que son realmente defini¬ 
ciones de vistas. 

La palabra clave new utilizada delante de T.saldo 
indica que debe utilizarse el valor de T.saldo posterior 
a la actualización; si se omite, se utilizará el valor pre¬ 
vio a la actualización. 


6.5. SEGURIDAD Y AUTORIZACIÓN 


Los datos guardados en la base de datos deben estar pro¬ 
tegidos contra los accesos no autorizados, de la destruc¬ 
ción o alteración malintencionadas además de la intro¬ 
ducción accidental de inconsistencias que evitan las 
restricciones de integridad. En este apartado se examina 
el modo en que se pueden utilizar mal los datos o hacer¬ 
los inconsistentes de manera intencionada. Se presentan 
luego mecanismos para protegerse de dichas incidencias. 

6.5.1. Violaciones de la seguridad 

Entre las formas de acceso malintencionado se encuen¬ 
tran: 

• La lectura no autorizada de los datos (robo de infor¬ 
mación) 

• La modificación no autorizada de los datos 

• La destrucción no autorizada de los datos 

La seguridad de las bases de datos se refiere a la 
protección frente a accesos malintencionados. No es posi¬ 
ble la protección absoluta de la base de datos contra el 
uso malintencionado, pero se puede elevar lo suficiente 
el coste para quien lo comete como para disuadir la 


mayor parte, si no la totalidad, de los intentos de tener 
acceso a la base de datos sin la autorización adecuada. 

Para proteger la base de datos hay que adoptar medi¬ 
das de seguridad en varios niveles: 

• Sistema de bases de datos. Puede que algunos 
usuarios del sistema de bases de datos sólo estén 
autorizados a tener acceso a una parte limitada de 
la base de datos. Puede que otros usuarios estén 
autorizados a formular consultas pero tengan prohi¬ 
bido modificar los datos. Es responsabilidad del 
sistema de bases de datos asegurarse de que no se 
violen estas restricciones de autorización. 

• Sistema operativo. Independientemente de lo 
seguro que pueda ser el sistema de bases de datos, 
la debilidad de la seguridad del sistema operativo 
puede servir como medio para el acceso no auto¬ 
rizado a la base de datos. 

• Red. Dado que casi todos los sistemas de bases de 
datos permiten el acceso remoto mediante termi¬ 
nales o redes, la seguridad en el nivel del softwa¬ 
re de la red es tan importante como la seguridad 
física, tanto en Internet como en las redes priva¬ 
das de las empresas. 
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• Físico. Los sitios que contienen los sistemas infor¬ 
máticos deben estar protegidos físicamente contra 
la entrada de intrusos. 

• Humano. Los usuarios deben ser autorizados cui¬ 
dadosamente para reducir la posibilidad de que 
alguno de ellos dé acceso a intrusos a cambio de 
sobornos u otros favores. 

Debe conservarse la seguridad en todos estos nive¬ 
les si hay que asegurar la seguridad de la base de datos. 
La debilidad de los niveles bajos de seguridad (físico o 
humano) permite burlar las medidas de seguridad estric¬ 
tas de niveles superiores (base de datos). 

En el resto de este apartado se aborda la seguridad 
en el nivel del sistema de bases de datos. La seguridad 
en los niveles físico y humano, aunque importante, cae 
fuera del alcance de este texto. 

La seguridad dentro del sistema operativo se aplica 
en varios niveles, que van desde las contraseñas para el 
acceso al sistema hasta el aislamiento de los procesos 
concurrentes que se ejecutan en el sistema. El sistema de 
archivos también proporciona algún nivel de protección. 
Las notas bibliográficas hacen referencia al tratamiento 
de estos temas en los textos sobre sistemas operativos. 
Finalmente, la seguridad en el nivel de la red ha logrado 
un amplio reconocimiento a medida que Internet ha pasa¬ 
do de ser una plataforma para la investigación académi¬ 
ca a convertirse en la base del comercio electrónico inter¬ 
nacional. Las notas bibliográficas muestran el tratamiento 
dado por los libros de texto a los principios básicos de la 
seguridad de las redes. Se presenta la discusión sobre la 
seguridad en términos del modelo relacional de datos, 
aunque los conceptos de este capítulo son igualmente 
aplicables a todos los modelos de datos. 

6.5.2. Autorizaciones 

Los usuarios pueden tener varios tipos de autorización 
para diferentes partes de la base de datos. Entre ellas 
están las siguientes: 

• La autorización de lectura permite la lectura de 
los datos, pero no su modificación. 

• La autorización de inserción permite la inser¬ 
ción de datos nuevos, pero no la modificación de 
los existentes. 

• La autorización de actualización permite la 
modificación de los datos, pero no su borrado. 

• La autorización de borrado permite el borrado 
de los datos. 

Los usuarios pueden recibir todos los tipos de auto¬ 
rización, ninguno de ellos o una combinación determi¬ 
nada de los mismos. 

Además de estas formas de autorización para el acce¬ 
so a los datos, los usuarios pueden recibir autorización 
para modificar el esquema de la base de datos: 


• La autorización de índices permite la creación 
y borrado de índices. 

• La autorización de recursos permite la creación 
de relaciones nuevas. 

• La autorización de alteración permite el añadi¬ 
do o el borrado de atributos de las relaciones. 

• La autorización de eliminación permite el borra¬ 
do de relaciones. 

Las autorizaciones de eliminación y de borrado 
se diferencian en que la autorización de borrado sólo 
permite el borrado de tupias. Si un usuario borra todas 
las tupias de una relación, la relación sigue existien¬ 
do, pero está vacía. Si se elimina una relación, deja de 
existir. 

La capacidad de crear nuevas relaciones queda regu¬ 
lada mediante la autorización de recursos. El usuario 
con la autorización de recursos que crea una relación 
nueva recibe automáticamente todos los privilegios 
sobre la misma. 

La autorización de índices puede parecer innecesa¬ 
ria, dado que la creación o borrado de un índice no afec¬ 
ta a los datos de las relaciones. Más bien, los índices 
son una estructura para las mejoras de rendimiento. Sin 
embargo, los índices también ocupan espacio y se exi¬ 
ge que todas las modificaciones de las bases de datos 
actualicen los índices. Si se concediera a todos los usua¬ 
rios la autorización de índices, los que llevaran a cabo 
actualizaciones estarían tentados de borrar los índices, 
mientras que los que formularan consultas estarían ten¬ 
tados de crear numerosos índices. Para permitir al admi¬ 
nistrador de la base de datos que regule el uso de los 
recursos del sistema es necesario tratar la creación de 
índices como un privilegio. 

La forma superior de autoridad es la concedida al 
administrador de la base de datos. El administrador de 
la base de datos puede autorizar usuarios nuevos, rees¬ 
tructurar la base de datos, etcétera. Esta forma de auto¬ 
rización es análoga a la proporcionada al superusua- 
rio u operador del sistema operativo. 

6.5.3. Autorizaciones y vistas 

En el Capítulo 3 se introdujo el concepto de las vistas 
como medio de proporcionar a un usuario un modelo 
personalizado de la base de datos. Una vista puede ocul¬ 
tar los datos que un usuario no necesita ver. La capaci¬ 
dad de las vistas para ocultar datos sirve para simplifi¬ 
car el uso del sistema y para mejorar la seguridad. El 
uso del sistema se simplifica porque se permite al usua¬ 
rio restringir su atención a los datos de interés. Aunque 
puede que se niegue el acceso directo a una relación, 
puede que se le permita el acceso a parte de esa rela¬ 
ción mediante una vista. Por tanto, se puede utilizar una 
combinación de seguridad en el nivel relacional y en el 
nivel de las vistas para limitar el acceso de un usuario 
precisamente a los datos que necesita. 
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En el ejemplo bancario considérese un empleado que 
necesita saber los nombres de todos los clientes que tie¬ 
nen un préstamo en cada sucursal. Este empleado no está 
autorizado a ver la información concerniente a los prés¬ 
tamos concretos que pueda tener cada cliente. Por tan¬ 
to, se le debe negar el acceso directo a la relación prés¬ 
tamo. Pero si va a tener acceso a la información necesaria 
se le debe conceder acceso a la vista cliente-préstamo , 
que consiste sólo en los nombres de los clientes y las 
sucursales en los que tienen un préstamo. Esta vista se 
puede definir en SQL de la manera siguiente: 

create view cliente-préstamo as 

(select nombre-sucursal, nombre-cliente 
from prestatario, préstamo 
where prestatario.número-préstamo 
= préstamo.número-préstamo) 

Supóngase que el empleado formula la siguiente con¬ 
sulta SQL: 


select * 

from préstamo-cliente 

Evidentemente, el empleado está autorizado a ver el 
resultado de esta consulta. Sin embargo, cuando el pro¬ 
cesador de consultas traduce la consulta en una consul¬ 
ta sobre las relaciones reales de la base de datos, se obtie¬ 
ne una consulta sobre prestatario y préstamo. Por tanto, 
se debe comprobar la autorización de la consulta del 
empleado antes de que comience el procesamiento de 
la misma. 

La creación de vistas no necesita la autorización de 
recursos. El usuario que crea una vista no recibe nece¬ 
sariamente todos los privilegios sobre la misma. Ese 
usuario sólo recibe los privilegios que no proporcionan 
autorizaciones adicionales respecto de las que ya posee. 
Por ejemplo, un usuario no puede recibir la autoriza¬ 
ción de actualización sobre una vista sin tener la auto¬ 
rización de actualización sobre las relaciones utiliza¬ 
das para definir la vista. Si un usuario crea una vista 
sobre la que no se puede conceder ninguna autoriza¬ 
ción, se deniega la solicitud de creación de la vista. En 
el ejemplo de la vista cliente-préstamo, el creador de la 
vista debe tener autorización de lectura sobre las rela¬ 
ciones prestatario y préstamo. 

6.5.4. Concesión de privilegios 

El usuario al que se le ha concedido alguna forma de 
autorización puede ser autorizado a transmitir esa auto¬ 
rización a otros usuarios. Sin embargo, hay que tener 
cuidado con el modo en que se puede transmitir la auto¬ 
rización entre los usuarios para asegurar que la misma 
pueda retirarse en el futuro. 

Considérese, a modo de ejemplo, la concesión de la 
autorización de actualización sobre la relación présta¬ 
mo de la base de datos bancaria. Supóngase que, ini¬ 


cialmente, el administrador de la base de datos concede 
autorización de actualización sobre préstamo a los usua¬ 
rios i/,, U 2 y U 3 , que, a su vez, pueden transmitirla a 
otros usuarios. La transmisión de la autorización de un 
usuario a otro puede representarse mediante un grafo de 
autorización. Los nodos de este grafo son los usuarios. 
Se incluye un arco U¡ —* U¡ en el grafo si el usuario U¡ 
concede la autorización de actualización sobre présta¬ 
mo a Uj. La raíz del grafo es el administrador de la base 
de datos. En la Figura 6.6 aparece un grafo sencillo. 
Obsérvese que tanto U¡ como U 2 conceden autorización 
al usuario í/ 5 ; sólo U ] concede autorización a U 4 . 

Un usuario tiene autorización si y sólo si hay un cami¬ 
no desde la raíz del grafo de autorización (es decir, el 
nodo que representa al administrador de la base de datos) 
hasta el nodo que representa a ese usuario. 

Un par de usuarios taimados podría intentar eludir 
las reglas de retirada de autorizaciones concediéndose 
autorización mutuamente, como se muestra en la Figu¬ 
ra 6.7a. Si el administrador de la base de datos retira la 
autorización a U 2 , U 2 la conserva mediante U 3 , como se 
muestra en la Figura 6.7b. Si a continuación se retira la 
autorización a U 3 , U 3 parece conservarla mediante U 2 , 
como se muestra en la Figura 6.7.c. Sin embargo, cuan¬ 
do el administrador retira la autorización a U 3 , los arcos 
de U 3 aU 2 y de U 2 a U 3 ya no forman parte de ningún 
camino que comience en el administrador de la base de 
datos. Hace falta que todos los arcos de un grafo de auto¬ 
rización sean parte de algún camino que comience en 
el administrador de la base de datos. Estos arcos se 
borran; el grafo de autorización resultante queda como 
se muestra en la Figura 6.8. 

Se requiere que todos los arcos de un grafo de auto¬ 
rización sean parte de algún camino que se origine en 
el administrador de la base de datos. Los arcos entre U 2 
y U 3 se borran, y el grafo de autorización es como el 
mostrado en la Figura 6.8. 

6.5.5. El concepto de papel 

Considérese un banco que tiene muchos cajeros. Cada 
cajero debe tener los mismos tipos de autorizaciones 




FIGURA 6.6. Grafo de concesión de autorizaciones. 
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( b) (C) 

FIGURA 6.7. Intento de eludir la retirada de autorizaciones. 


para el mismo conjunto de relaciones. Cada vez que se 
contrata un nuevo cajero hay que darle todas esas auto¬ 
rizaciones individualmente. 

Un esquema mejor sería especificar las autorizacio¬ 
nes que deben tener los cajeros e identificar separada¬ 
mente cuáles de los usuarios de la base de datos son 
cajeros. El sistema puede usar estas dos piezas de infor¬ 
mación para determinar las autorizaciones de cada per¬ 
sona que sea un cajero. Cuando se contrate a una nue¬ 
va persona como cajero, se le debe asignar un 
identificador de usuario e identificarle como cajero. Ya 
no es necesario especificar permisos individuales para 
los cajeros. 

Los papeles capturan este esquema. En la base de 
datos se crea un conjunto de papeles. Las autorizacio¬ 
nes se conceden a los papeles, de igual modo que se 
conceden a usuarios individuales. Se concede un con¬ 
junto de papeles a cada usuario de la base de datos (que 
puede ser vacío) para los que está autorizado. 

En el ejemplo bancario, algunos ejemplos de pape¬ 
les serían cajero, gestor-sucursal, auditor y adminis- 
trador-del-sistema. 

Una alternativa menos preferible sería crear un iden¬ 
tificador de usuario cajero y permitir que cada cajero se 
conectase a la base de datos usando este identificador. 
El problema con este esquema es que no sería posible 
identificar exactamente al cajero que ha realizado una 
determinada transacción, conduciendo a problemas de 
seguridad. El uso de los papeles tiene la ventaja de 
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ti, U 2 U 3 

FIGURA 6.8. Grato de autorización. 


requerir a los usuarios que se conecten con su propio 
identificador de usuario. 

Cualquier autorización que se pueda conceder a un 
usuario se puede conceder a un papel. Los papeles se 
conceden a los usuarios al igual que las autorizaciones. 
Y, como otras autorizaciones, un usuario también pue¬ 
de conceder autorización para conceder un papel par¬ 
ticular a otros. Así, los gestores de las sucursales pue¬ 
den tener autorización de concesión para conceder el 
papel cajero. 

6.5.6. Trazas de auditoría 

Muchas aplicaciones de bases de datos seguras requie¬ 
ren que se mantenga una traza de auditoría. Una tra¬ 
za de auditoría es un registro histórico de todos los cam¬ 
bios (inserciones, borrados o actualizaciones) de la base 
de datos, junto con información sobre el usuario que 
realizó el cambio y en qué momento. 

La traza de auditoría ayuda a la seguridad de for¬ 
mas diferentes. Por ejemplo, si el saldo de una cuenta 
es incorrecto, el banco desearía revisar todas las actua¬ 
lizaciones realizadas sobre la cuenta para encontrar las 
actualizaciones incorrectas (o fraudulentas), así como 
las personas que realizaron los cambios. El banco podría 
entonces usar la traza de auditoría para revisar todas 
las actualizaciones realizadas por estas personas para 
encontrar las actualizaciones incorrectas o fraudu¬ 
lentas. 

Es posible crear una traza de auditoría definiendo 
disparadores adecuados sobre las actualizaciones de las 
relaciones (usando variables definidas del sistema que 
identifican el nombre de usuario y la hora). Sin embar¬ 
go, muchos sistemas de bases de datos proporcionan 
mecanismos incorporados para crear trazas de audito¬ 
ría que son más convenientes de usar. Los detalles de 
la creación de las trazas de auditoría varían entre los sis¬ 
temas de bases de datos y se deben consultar los manua¬ 
les para los detalles. 
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6.6. AUTORIZACIÓN EN SQL 


El lenguaje SQL ofrece un mecanismo bastante poten¬ 
te para la definición de autorizaciones. En este apar¬ 
tado se describen estos mecanismos y sus limitacio¬ 
nes. 

6.6.1. Privilegios en SQL 

La norma SQL incluye los privilegios delete, insert, 
select y update El privilegio select se corresponde con 
el privilegio de lectura. SQL también incluye un privi¬ 
legio references que permite a un usuario o papel decla¬ 
rar claves externas al crear relaciones. Si la relación que 
se va a crear incluye una clave externa que hace refe¬ 
rencia a atributos de otra relación, el usuario o papel 
debe haber recibido el privilegio references sobre esos 
atributos. El motivo de que el privilegio references sea 
una característica útil es algo sutil y se explica más ade¬ 
lante en este mismo apartado. 

El lenguaje de definición de datos de SQL incluye 
órdenes para conceder y retirar privilegios. La instruc¬ 
ción grant se utiliza para conferir autorizaciones. La 
forma básica de esta instrucción es la siguiente: 

grant <lista de privilegios> on <nombre de relación o 
de lista> to <lista de usuarios/papeles> 

La lista de privilegios permite la concesión de varios 
privilegios con una sola orden. 

La siguiente instrucción grant concede a los usua¬ 
rios U { , U 2 y U 3 la autorización select sobre la relación 
sucursal'. 

grant select on sucursal to tTj, U 2 , U 3 

La autorización update puede concederse sobre todos 
los atributos de la relación o sólo sobre algunos. Si se 
incluye la autorización update en una instrucción grant, 
la lista de atributos sobre los que se va a conceder la 
autorización update opcionalmente aparece entre parén¬ 
tesis justo después de la palabra clave update. Si se 
omite la lista de atributos se concede el privilegio upda¬ 
te sobre todos los atributos de la relación. 

La siguiente instrucción grant concede a los usua¬ 
rios U v , U 2 y U 3 la autorización update sobre el atribu¬ 
to importe de la relación préstamo'. 

grant update ( importe ) on préstamo to £/,, U 2 , U 3 

En SQL el privilegio insert también puede especifi¬ 
car una lista de atributos; cualquier inserción en la rela¬ 
ción debe especificar sólo esos atributos y al resto de 
los atributos se les conceden valores predeterminados 
(si hay alguno definido para ellos) o se les da el valor 
nulo. 


El privilegio SQL references se concede sobre atri¬ 
butos concretos de manera parecida a la mostrada para 
el privilegio update. La siguiente instrucción grant per¬ 
mite al usuario U x crear relaciones que hagan referen¬ 
cia a la clave nombre-sucursal de la relación sucursal 
como si fuera una clave externa: 

grant references ( nombre-sucursal ) on sucursal to U¡ 

En un principio puede parecer que no hay ningún moti¬ 
vo para evitar que los usuarios creen claves externas 
que hagan referencia a otra relación. Sin embargo, hay 
que recordar del Apartado 6.2 que las restricciones de 
las claves externas limitan las operaciones de borrado 
y de actualización sobre la operación a la que hacen 
referencia. En el ejemplo anterior, si U t crea una clave 
externa en una relación r que haga referencia al atribu¬ 
to nombre-sucursal de la relación sucursal y luego in¬ 
serta en r una tupia correspondiente a la sucursal de 
Navacerrada, ya no es posible borrar la sucursal 
de Navacerrada de la relación sucursal sin modificar 
también la relación r. Por tanto, la definición de una cla¬ 
ve extema por U x limita la actividad futura de los demás 
usuarios; por tanto, el privilegio references es nece¬ 
sario. 

El privilegio all privileges puede utilizarse como una 
forma abreviada de todos los privilegios que se pueden 
conceder. De manera parecida, el nombre de usuario 
public hace referencia a todos los usuarios presentes y 
futuros del sistema. SQL incluye también un privilegio 
usage que autoriza a un usuario a utilizar un dominio 
especificado (recuérdese que el dominio se correspon¬ 
de con el concepto de tipo de un lenguaje de programa¬ 
ción y puede ser definido por el usuario). 

6.6.2. Papeles 

Los papeles se pueden crear en SQL: 1999 como sigue 

create role cajero 

Se pueden conceder privilegios a los papeles al igual 
que a los usuarios, como se ilustra en la siguiente ins¬ 
trucción 

grant select on cuenta 
to cajero 

Los papeles se pueden asignar a los usuarios, así como 
a otros papeles, como muestran estas instrucciones. 

grant cajero to juan 
create role gestor 
grant cajero to gestor 
grant gestor to maría 
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Los privilegios de un usuario o papel consisten en: 

• Todos los privilegios concedidos directamente al usua¬ 
rio o papel. 

• Todos los privilegios concedidos a papeles que se 
hayan concedido al usuario o papel. 

Nótese que puede haber una cadena de papeles; por 
ejemplo, el papel empleado se puede conceder a todos 
los cajeros. A su vez, el papel cajero se concede a todos 
los gestores. Así, el papel gestor hereda todos los pri¬ 
vilegios concedidos a los papeles empleados y cajeros 
además de los privilegios concedidos directamente a 
gestor. 

6.6.3. El privilegio de conceder privilegios 

Un usuario o papel al que se le concede un privilegio 
no está autorizado de manera predeterminada a conce¬ 
dérselo a otros usuarios o papeles. Si se desea conceder 
un privilegio a un usuario y permitirle que lo transmi¬ 
ta a otros usuarios hay que añadir la cláusula with grant 
option a la orden grant correspondiente. Por ejemplo, 
si se desea conceder a U l el privilegio select sobre sucur¬ 
sal y que pueda transmitirlo a otros, hay que escribir 

grant select on sucursal to U ] with grant option 

Para retirar una autorización se utiliza la instrucción 
revoke. Adopta una forma casi idéntica a la de grant: 

revoke <lista de privilegios> on cnombre de relación 
o de vista> 

from <lista de usuarios o papeles> [restrict I Cascade] 

Por tanto, para retirar los privilegios que se han con¬ 
cedido con anterioridad hay que escribir 

revoke select on sucursal from U u U 2 , U 3 

revoke update ( importe) on préstamo from U u U 2 , U 2 
revoke references ( nombre-sucursal ) on sucursal 

from t/j 

Como se vio en el Apartado 6.5.4, la retirada de un pri¬ 
vilegio a un usuario o papel puede hacer que otros usua¬ 
rios o papeles también lo pierdan. Este comportamien¬ 
to se denomina retirada en cadena. En la mayoría de 
los sistemas de bases de datos, la retirada en cascada es 
el comportamiento predeterminado; por tanto, la pala¬ 
bra clave Cascade se puede omitir como se ha hecho en 
los ejemplos anteriores. La instrucción revoke también 
puede especificar restrict: 

revoke select on sucursal from ÍTj, U 2 , t/ 3 restrict 

En este caso se devuelve un error si hay alguna retira¬ 
da de privilegios en cadena y en este caso la acción de 
retirada de privilegios no se lleva a cabo. La siguiente 


instrucción revoke sólo anula la opción de concesión 
grant y no el propio privilegio select. 

revoke grant option for select on sucursal from U l 

6.6.4. Otras características 

El creador de un objeto (relación, vista o papel) obtie¬ 
ne todos los privilegios sobre el objeto, incluyendo el 
privilegio de conceder privilegios a otros. 

La norma SQL especifica un mecanismo primitivo 
de autorización para el esquema de la base de datos: sólo 
el propietario del esquema puede ejecutar cualquier 
modificación del esquema. Por tanto, las modificacio¬ 
nes del esquema —como la creación o borrado de las 
relaciones, la adición o eliminación de atributos de las 
relaciones y la adición o eliminación de índices— sólo 
pueden ser ejecutadas por el propietario del mismo. 
Varias implementaciones de las bases de datos tienen 
mecanismos de autorización más potentes para los esque¬ 
mas de las bases de datos, parecidos a los discutidos 
anteriormente, pero esos mecanismos no son estándar. 

6.6.5. Limitaciones de la autorización SQL 

Las normas SQL actuales de autorización tienen algu¬ 
nas deficiencias. Por ejemplo, supóngase que se desea 
que todos los estudiantes sean capaces de ver sus pro¬ 
pias notas, pero no las del resto. La autorización debe 
estar en el nivel de las tupias, lo cual no es posible en 
los estándares de autorización de SQL. 

Más aún, con el crecimiento de Web, los accesos a 
bases de datos vienen principalmente de los servidores 
de aplicaciones Web. Los usuarios finales puede que no 
tengan identificadores de usuario individuales en la base 
de datos y realmente puede que haya sólo un único iden- 
tificador de usuario en la base de datos que correspon¬ 
da a todos los usuarios del servidor de aplicaciones. 

La tarea de la autorización recae entonces sobre el ser¬ 
vidor de aplicaciones; el esquema completo de autoriza¬ 
ción de SQL se omite. El beneficio es que la aplicación 
puede implementar las autorizaciones de grano fino, como 
las de las tupias individuales. Estos son los problemas: 

• El código para comprobar la autorización se entre¬ 
mezcla con el resto del código de la aplicación. 

• La implementación de la autorización mediante 
código de aplicación, en lugar de realizarlo decla¬ 
rativamente con SQL, hace que sea difícil asegu¬ 
rar la ausencia de agujeros de seguridad. Debido 
a un descuido, uno de los programas de aplicación 
podría no comprobar la autorización, permitiendo 
el acceso de usuarios no autorizados a datos con¬ 
fidenciales. La verificación de que todos los pro¬ 
gramas de aplicación realizan todas las compro¬ 
baciones de autorización implica la lectura de todo 
el código del servidor de la aplicación, una tarea 
formidable en un gran sistema. 
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6.7. CIFRADO Y AUTENTICACIÓN 


Puede que las diferentes provisiones para la autoriza¬ 
ción que haga un sistema de bases de datos no propor¬ 
cionen suficiente protección para los datos extremada¬ 
mente delicados. En tales casos se pueden cifrar los 
datos. Los datos cifrados no se pueden leer a menos que 
el lector sepa la manera de descifrarlos (descodificar¬ 
los). El cifrado también forma la base de los buenos 
esquemas para la autenticación de usuarios en una base 
de datos. 

6.7.1. Técnicas de cifrado 

Hay un enorme número de técnicas para el cifrado de 
los datos. Puede que las técnicas de cifrado sencillas no 
proporcionen la seguridad adecuada, dado que puede 
ser sencillo para un usuario no autorizado romper el 
código. Como ejemplo de una técnica de cifrado débil 
considérese la sustitución de cada carácter por el siguien¬ 
te en el alfabeto. Así, 

Navacerrada 

se transforma en 

Ñbwbdfssbeb 

Si un usuario no autorizado sólo lee «Ñbwbdfssbeb» 
probablemente no tenga la información suficiente para 
romper el código. Sin embargo, si el intruso ve un gran 
número de nombres de sucursales codificados puede uti¬ 
lizar los datos estadísticos referentes a la frecuencia rela¬ 
tiva de los caracteres para averiguar el tipo de sustitu¬ 
ción realizado (por ejemplo, en inglés la E es la más 
frecuente, seguida por T, A, O. N, I, ...). 

Una buena técnica de cifrado tiene las propiedades 
siguientes: 

• Es relativamente sencillo para los usuarios autori¬ 
zados cifrar y descifrar los datos. 

• El esquema de cifrado no depende de lo poco cono¬ 
cido que sea el algoritmo, sino más bien de un pará¬ 
metro del algoritmo denominado clave de cifrado. 

• Es extremadamente difícil para un intruso deter¬ 
minar la clave de cifrado. 

Un enfoque, la norma de cifrado de datos (Data 
Encription Standard, DES) realiza una sustitución de 
caracteres y una reordenación de los mismos en función 
de una clave de cifrado. Para que este esquema funcio¬ 
ne los usuarios autorizados deben proveerse de la cla¬ 
ve de cifrado mediante un mecanismo seguro. Este 
requisito es una debilidad importante, dado que el esque¬ 
ma no es más seguro que el mecanismo por el que se 
transmite la clave de cifrado. La norma DES se reafir¬ 


mó en 1983, 1987 y de nuevo en 1993. Sin embargo, la 
debilidad de DES se reconoció en 1993 cuando se nece¬ 
sitó una nueva norma denominada norma de cifrado 
avanzado (Advanced Encription Standard, AES). En el 
año 2000, el algoritmo Rijndael (denominado así por 
sus inventores, V. Rijmen y J. Daemen) se seleccionó 
para ser la norma AES. Este algoritmo se eligió por su 
nivel significativamente más fuerte de seguridad y su 
facilidad relativa de implementación en los sistemas 
informáticos actuales, así como en dispositivos como 
tarjetas inteligentes. Al igual que la norma DES, el algo¬ 
ritmo Rijndael es un algoritmo de clave compartida (o 
clave simétrica) en el que los usuarios autorizados com¬ 
parten una clave. 

El cifrado de clave pública es un esquema alterna¬ 
tivo que evita parte de los problemas que se afrontan 
con DES. Se basa en dos claves; una clave pública y 
una clave privada. Cada usuario U¡ tiene una clave públi¬ 
ca C, y una clave privada D¡. Todas las claves públicas 
están publicadas: cualquiera puede verlas. Cada clave 
privada sólo la conoce el usuario al que pertenece. Si el 
usuario U¡ desea guardar datos cifrados, los cifra utili¬ 
zando la clave pública Cj. Descifrarlos requiere la cla¬ 
ve privada Dj. 

Como la clave de cifrado de cada usuario es públi¬ 
ca es posible intercambiar información de manera segu¬ 
ra utilizando este esquema. Si el usuario Cj desea com¬ 
partir los datos con U 2 los codifica utilizando E 2 , la clave 
pública de U 2 . Dado que sólo el usuario U 2 conoce la 
manera de descifrar los datos, la información se trans¬ 
mite de manera segura. 

Para que el cifrado de clave pública funcione debe 
haber un esquema de cifrado que pueda hacerse públi¬ 
co sin permitir a la gente descubrir el esquema de des¬ 
cifrado. En otros términos, debe ser difícil deducir la 
clave privada dada la clave pública. Existe un esquema 
de ese tipo y se basa en lo siguiente: 

• Hay un algoritmo eficiente para comprobar si un 
número es primo. 

• No se conoce ningún algoritmo eficiente para 
encontrar los factores primos de un número. 

Para los fines de este esquema los datos se tratan 
como una colección de enteros. Se crea una clave públi¬ 
ca calculando el producto de dos números primos gran¬ 
des: fj y P 2 . La clave privada consiste en el par (/j, P 2 ) 
y el algoritmo de descifrado no se puede utilizar con 
éxito si sólo se conoce el producto P\P 2 . Dado que todo 
lo que se publica es el producto P\P 2 , un usuario no 
autorizado debería poder factorizar P { P 2 para robar 
datos. Eligiendo P 1 y P 2 suficientemente grandes (por 
encima de 100 dígitos) se puede hacer el coste de la fac- 
torización prohibitivamente elevado (del orden de años 
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de tiempo de cálculo, incluso en las computadoras más 
rápidas). 

En las notas bibliográficas se hace referencia a los 
detalles del cifrado de clave pública y la justificación 
matemática de las propiedades de esta técnica. 

Pese a que el cifrado de clave pública que utiliza el 
esquema descrito es seguro, también es costoso en cuan¬ 
to a cálculo. Un esquema híbrido utilizado para la comu¬ 
nicación segura es el siguiente: las claves DES se inter¬ 
cambian mediante un esquema de cifrado de clave 
pública y posteriormente se utiliza el cifrado DES con 
los datos transmitidos. 

6.7.2. Autenticación 

La autenticación se refiere a la tarea de verificar la iden¬ 
tidad de una persona o software que se conecte a una 
base de datos. La forma más simple consiste en una con¬ 
traseña secreta que se debe presentar cuando se abra una 
conexión a la base de datos. 

La autenticación basada en palabras clave se usa 
ampliamente por los sistemas operativos y bases de 
datos. Sin embargo, el uso de contraseñas tiene algunos 
inconvenientes, especialmente en una red. Si un hus- 
meador es capaz de «oler» los datos que circulan por la 
red, puede ser capaz de encontrar la contraseña que se 
está enviando por la red. Una vez que el husmeador tie¬ 
ne un usuario y contraseña, se puede conectar a la base 
de datos pretendiendo que es el usuario legítimo. 

Un esquema más seguro es el sistema de desafío- 
respuesta. El sistema de bases de datos envía una cade¬ 
na de desafío al usuario. El usuario cifra la cadena de 
desafío usando una contraseña secreta como clave de 


cifrado y devuelve el resultado. El sistema de bases de 
datos puede verificar la autenticidad del usuario desci¬ 
frando la cadena con la mima contraseña secreta, y com¬ 
parando el resultado con la cadena de desafío original. 
Este esquema asegura que las contraseñas no circulen 
por la red. 

Los sistemas de clave pública se pueden usar para 
cifrar en un sistema de desafío-respuesta. El sistema de 
bases de datos cifra una cadena de desafío usando la 
clave pública del usuario y lo envía al usuario. Este des¬ 
cifra la cadena con su clave privada y devuelve el resul¬ 
tado al sistema de bases de datos. El sistema de bases 
de datos comprueba entonces la respuesta. Este esque¬ 
ma tiene la ventaja añadida de no almacenar la contra¬ 
seña en la base de datos, donde podría ser vista poten¬ 
cialmente por administradores del sistema. 

Otra aplicación interesante de la criptografía está en 
las firmas digitales para verificar la autenticidad de los 
datos; las firmas digitales desempeñan el papel electró¬ 
nico de las firmas físicas en los documentos. La clave 
privada se usa para firmar los datos y los datos firmados 
se pueden hacer públicos. Cualquiera podría verificar¬ 
los con la clave pública, pero nadie podría haber gene¬ 
rado los datos codificados sin tener la clave privada. Por 
tanto, se puede comprobar que los datos fueron creados 
realmente por la persona que afirma haberlos creado. 

Además, las firmas digitales también sirven para ase¬ 
gurar el rechazo. Es decir, en el caso de que una per¬ 
sona que creó los datos afirmase más tarde que no lo 
hizo (el equivalente electrónico de afirmar que no se ha 
firmado un talón) se puede probar que esa persona ha 
creado los datos (a menos que haya cedido su clave pri¬ 
vada a otros). 


6.8. RESUMEN 


• Las restricciones de integridad aseguran que las modi¬ 
ficaciones realizadas a la base de datos por los usua¬ 
rios autorizados no den lugar a la pérdida de la con¬ 
sistencia de los datos. 

• En capítulos anteriores se tomaron en consideración 
varios tipos de restricciones, incluyendo la declara¬ 
ción de claves y la declaración de la forma de las rela¬ 
ciones (de varios a varios, de varios a uno, de uno a 
uno). En este capítulo se han tomado en considera¬ 
ción otros tipos de restricciones y se han discutido 
mecanismos para asegurar el mantenimiento de es¬ 
tas restricciones. 

• Las restricciones de los dominios especifican el con¬ 
junto de valores que se pueden asociar con un atri¬ 
buto. Estas restricciones también pueden impedir el 
uso de valores nulos para atributos concretos. 

• Las restricciones de integridad referencial aseguran 
que un valor que aparece en una relación para un con¬ 


junto de atributos dado aparezca también para un 
conjunto de atributos concreto en otra relación. 

• Las restricciones de dominio y las de integridad refe¬ 
rencial son relativamente sencillas de verificar. El uso 
de restricciones más complejas puede provocar una 
sobrecarga considerable. Se han visto dos maneras de 
expresar restricciones más generales. Los asertos son 
expresiones declarativas que manifiestan predicados 
que deben ser siempre verdaderos. 

• Los disparadores definen las acciones que se deben 
ejecutar automáticamente cuando se producen ciertos 
eventos. Los disparadores tienen muchos usos, tales 
como la implementación de reglas de negocio, regis¬ 
tro histórico de la auditoría e incluso para realizar accio¬ 
nes fuera del sistema de bases de datos. Aunque los 
disparadores se añadieron tarde a la norma SQL como 
parte de SQL: 1999, la mayoría de sistemas de bases 
de datos los han implementado desde hace tiempo. 
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• Los datos guardados en las bases de datos deben pro¬ 
tegerse de los accesos no autorizados, de la destruc¬ 
ción malintencionada o de la alteración y de la intro¬ 
ducción accidental de inconsistencias. 

• Es más sencilla la protección contra la pérdida acci¬ 
dental de la consistencia de los datos que contra el 
acceso malintencionado a las bases de datos. La pro¬ 
tección total de las bases de datos contra las acciones 
malintencionadas no es posible, pero puede lograrse 
que el coste para quienes las cometan sea lo bastan¬ 
te elevado como para disuadir la mayor parte, si no a 
la totalidad, de los intentos de acceso a la base de datos 
sin la correspondiente autorización. 

• Los usuarios pueden tener varios tipos de autoriza¬ 
ción para diferentes partes de la base de datos. La 
autorización es un medio por el que se puede prote¬ 
ger al sistema de bases de datos contra los accesos 
malintencionados o no autorizados. 


• Los usuarios a los que se les haya concedido algún 
tipo de autorización pueden ser autorizados a trans¬ 
mitir la misma a otros usuarios. Sin embargo, hay que 
tomar precauciones respecto a la manera en que se 
pueden transmitir las autorizaciones entre los usua¬ 
rios si se debe asegurar que las mismas se podrán reti¬ 
rar en el futuro. 

• Los papeles facilitan la asignación de un conjunto de 
privilegios a un usuario de acuerdo al papel que el 
usuario desempeña en la organización. 

• Puede que las diferentes provisiones de autorización 
de los sistemas de bases de datos no proporcionen la 
protección suficiente para los datos más delicados. 
En tales casos se pueden cifrar los datos. Sólo quie¬ 
nes conozcan la manera de descifrar (descodificar) 
los datos cifrados podrán leerlos. El cifrado también 
forma la base de la autenticación segura de los usua¬ 
rios. 


TÉRMINOS DE REPASO 


• Aserto 

• Autenticación 

• Autorización 

• Cascada 

• Cifrado 

• Cifrado de clave pública 

• Cifrado de clave secreta 

• Cláusula check 

• Concesión de privilegios 

• Disparador 

• Disparadores before y after 

• Firma digital 

• Grafo de autorización 

• Integridad referencial 

• Modelo evento-condición-acción 

• Niveles de seguridad 

• Papeles 


Privilegios 

— Lectura 

— Inserción 

— Actualización 

— Borrado 

— índices 

— Recursos 

— Alteración 

— Eliminación 

— Concesión 

— Todos los privilegios 
Rechazo 

Restricción de clave externa 
Restricción de clave primaria 
Restricciones de los dominios 
Restricción de unicidad 
Seguridad de la base de datos 
Sistema de desafío-respuesta 
Variables y tablas de transición 


EJERCICIOS 


6.1. Complétese la definición del LDD de SQL de la base trabaja ( nombre-empleado , nombre-empresa, sueldo) 

de datos bancaria de la Figura 6.2 para incluir las reía- empresa ( nombre-empresa . ciudad) 

ciones préstamo y prestatario. jefe ( nombre-empleado , nombre-jefe) 


6.2. Considérese la siguiente base de datos relacional: 
empleado ( nombre-empleado , calle, ciudad) 
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Dese una definición en el LDD de SQL de esta base de 
datos. Identifiqúense las restricciones de integridad 
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referencial que deban cumplirse e incluyanse en la defi¬ 
nición del LDD. 

6.3. Las restricciones de integridad referencial tal y como 
se han definido en este capítulo implican exactamente 
a dos relaciones. Considérese una base de datos que 
incluye las relaciones siguientes: 

trabajador-fijo ( nombre, despacho, teléfono, sueldo) 
trabajador-tiempo-parcial ( nombre, sueldo-por-hora) 
dirección ( nombre, calle, ciudad) 

Supóngase que se desea exigir que cada nombre que 
aparece en dirección aparezca en trabajador-fijo o en 
trabajador-tiempo-parcial, pero no necesariamente en 
ambos. 

a. Propóngase una sintaxis para expresar esta restric¬ 
ción. 

b. Discútanse las acciones que debe realizar el siste¬ 
ma para aplicar una restricción de este tipo. 

6.4. SQL permite la dependencia de una clave externa para 
hacer referencia a la misma relación, como en el ejem¬ 
plo siguiente: 

create table jefe 

(: nombre-empleado char (20) not nuil 
nombre-jefech&r (20) not nuil, 
primary key nombre-empleado, 
foreign key ( nombre-jefe) references jefe 
on delete cascade) 

Aquí, nombre-empleado es una clave de la tabla direc¬ 
tor, lo que significa que cada empleado tiene como 
máximo un director. La orden de clave externa exige 
que cada director sea también empleado. Expliqúese 
exactamente lo que ocurre cuando se borra una tupia 
de la relación jefe. 

6.5. Supóngase que hay dos relaciones r y s tales que la 
clave externa B de r hace referencia a la clave prima¬ 
ria A de s. Descríbase la manera en que puede utili¬ 
zarse el mecanismo de los disparadores para imple- 
mentar la opción on delete cascade cuando se borra 
una tupia de s. 

6.6. Escríbase un aserto para la base de datos bancaria que 
asegure que el valor del activo de la sucursal de Nava- 
cerrada sea igual a la suma de todos los importes pres¬ 
tados por esa sucursal. 

6.7. Escríbase un disparador SQL para realizar la siguien¬ 
te acción: cuando se borre una cuenta, comprobar para 
cada tenedor de la cuenta si tiene otras cuentas y, si no, 
borrarlo de la relación impositor. 

6.8. Considérese la vista sucursal-cliente definida como 
sigue: 

create view sucursal-cliente as 

select nombre-sucursal, nombre-cliente 


from impositor, cuenta 
where impositor.mímero-cuenta 
= cuenta.número-cuenta 

Supóngase que la vista está materializada, es decir, la 
vista se calcula y se almacena. Escríbanse reglas acti¬ 
vas para mantener la vista, es decir, mantenerla actua¬ 
lizada según las inserciones y borrados en impositor o 
cuenta. No hay que preocuparse de las actualizaciones. 

6.9. Confecciónese una lista de los problemas de seguridad 
de un banco. De cada elemento de la lista hay que decir 
si afecta a la seguridad física, a la personal, a la del sis¬ 
tema operativo o a la de las bases de datos. 

6.10. Utilizando las relaciones de la base de datos bancaria 
de ejemplo escríbase una expresión SQL para definir 
las vistas siguientes: 

a. Una vista que contenga los números de cuenta y los 
nombres de los clientes (pero no los saldos) de todas 
las cuentas de la sucursal de El Escorial. 

b. Una vista que contenga el nombre y la dirección de 
todos los clientes que tengan cuenta en el banco pero 
no tengan ningún préstamo. 

c. Una vista que contenga el nombre y el saldo medio 
de la cuenta de cada cliente de la sucursal de Colla¬ 
do Villalba. 

6.11. Para cada una de las vistas definidas en el Ejercicio 6.10 
expliqúese la manera en que deben realizarse las actua¬ 
lizaciones (si es que se deben permitir). Sugerencia: 
véase la discusión de las vistas en el Capítulo 3. 

6.12. En el Capítulo 3 se describió el uso de las vistas para 
facilitar el acceso a la base de datos de los usuarios que 
sólo necesiten ver una parte de la misma. En este capí¬ 
tulo se ha descrito el uso de las vistas como mecanis¬ 
mo de seguridad. ¿Pueden entrar en conflicto estas dos 
finalidades de las vistas? Expliqúese la respuesta. 

6.13. ¿Cuál es la finalidad de tener categorías diferentes para 
la autorización de índices y para la de recursos? 

6.14. Los sistemas de bases de datos que guardan cada rela¬ 
ción en un archivo diferente del sistema operativo pue¬ 
den utilizar los esquemas de seguridad y de autoriza¬ 
ción del sistema operativo en lugar de definir un 
esquema especial propio. Discútanse las ventajas e 
inconvenientes de ese enfoque. 

6.15. ¿Cuáles son las dos ventajas de cifrar los datos guar¬ 
dados en una base de datos? 

6.16. Quizás los elementos de datos más importantes de cual¬ 
quier sistema de bases de datos sean las contraseñas 
que controlan el acceso a la base de datos. Propónga¬ 
se un esquema para guardar de manera segura las con¬ 
traseñas. Asegúrese de que el esquema permita al sis¬ 
tema comprobar las contraseñas proporcionadas por 
los usuarios que intenten iniciar una sesión en el mis¬ 
mo. 
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NOTAS BIBLIOGRÁFICAS 


En Hammer y McLeod [1975], Stonebraker [1975], 
Eswaran y Chamberlin [1975], Schmid y Swenson 
[1975] y en Codd [1979] se ofrecen discusiones sobre 
las restricciones de integridad en el modelo relacional. 
Las propuestas originales de SQL para los asertos y los 
disparadores se discuten en Astrahan et al. [1976], 
Chamberlin et al. [1976] y en Chamberlin et al. [1981]. 
Véanse las notas bibliográficas del Capítulo 4 para obte¬ 
ner referencias de las normas SQL. 

Las discusiones referentes al mantenimiento eficiente 
y a la comprobación de los asertos de integridad semán¬ 
tica se ofrecen en Hammer y Sarin [1978], Badal y 
Popek [1979], Bernstein et al. [1980a], Hsu e Imielins- 
ki [1985], McCune y Henschen [1989] y Chomicki 
[1992a]. Una alternativa al uso de comprobaciones de 
integridad en tiempo de ejecución es certificar la correc¬ 
ción de los programas que tienen acceso a la base de 
datos. Este enfoque se discute en Sheard y Stemple 
[1989]. 

Las bases de datos activas son bases de datos que 
soportan disparadores y otros mecanismos que permi¬ 
ten a la base de datos realizar acciones cuando sucedan 
eventos. En McCarthy y Dayal [1989] se discute la 
arquitectura de un sistema de bases de datos activas 
basado en el formalismo evento-condición-acción. 
Widom y Linkelstein [1990] describen la arquitectura 
de un sistema de reglas basado en reglas orientadas a 
conjuntos; la implementación de un sistema de reglas 
en el sistema de bases de datos extensibles Starbust se 
presenta en Widom et al. [1991]. Considérese un meca¬ 
nismo de ejecución que permita la elección no deter¬ 
minista de la regla a ejecutar a continuación. Se dice 
que un sistema de reglas es confluente si, indepen¬ 
dientemente de la regla elegida, el estado final es el mis¬ 
mo. Los aspectos de terminación, no deterninismo y 


confluencia de los sistemas de reglas se discuten en 
Aiken et al. [1995]. 

Los aspectos de la seguridad de los sistemas infor¬ 
máticos en general se discuten en Bell y LaPadula [1976] 
y en el Departamento de Defensa de EE.UU. [U.S. Dept. 
of Defense 1985]. Los aspectos de la seguridad de SQL 
se pueden encontrar en las normas de SQL y en los libros 
de texto sobre SQL referenciados en las notas biblio¬ 
gráficas del Capítulo 4. 

Stonebraker y Wong [1974] estudian el enfoque de 
la seguridad de Ingres, que implica la modificación de 
las consultas de los usuarios para asegurar que los usua¬ 
rios no tienen acceso a datos para los que no se les ha 
concedido autorización. Denning y Denning [1979] pre¬ 
sentan una visión del estado del arte de la seguridad de 
las bases de datos. 

Los sistemas de bases de datos que pueden producir 
respuestas erróneas cuando es necesario para el mante¬ 
nimiento de la seguridad se discuten en Winslett et al. 
[1994] y en Tendick y Matloff [1994]. El trabajo en la 
seguridad de las bases de datos relaciónales incluye el de 
Stachour y Thuraisingham [1990], Jajodia y Sandhu 
[1990], Kogan y Jajodia [1990] y Qian y Lunt [1996]. 
Los aspectos de la seguridad de los sistemas operativos 
se discuten en la mayor parte de los textos sobre sistemas 
operativos, incluyendo a Silberschatz y Galvin [1998]. 

Stallings [1998] proporciona una descripción en un 
libro de texto de la criptografía. Daemen y Rijmen 
[2000] presentan el algoritmo Rjndael. El Departamento 
de Comercio de EE. UU. [U.S. Dept. of Commerce 
1977] presentó la norma para cifrado de datos. El cifra¬ 
do mediante clave pública se discute en Rivest et al. 
[1978]. Otras discusiones sobre criptografía incluyen 
las de Diffie y Hellman [1979], Simmons [1979], Ler- 
nández et al. [1981] y Akl [1983]. 
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CAPÍTULO 

DISEÑO DE BASES 
DE DATOS RELACIONALES 


E ste capítulo continúa el estudio de los problemas de diseño de las bases de datos rela¬ 
ciónales. En general, el objetivo del diseño de las bases de datos relaciónales es la gene¬ 
ración de un conjunto de esquemas relaciónales que nos permita almacenar la informa¬ 
ción sin redundancias innecesarias, pero que también nos permita recuperar fácilmente esa 
información. Un enfoque es el diseño de esquemas que se hallen en una forma normal ade¬ 
cuada. Para determinar si el esquema de una relación se halla en una de las formas normales 
deseables hace falta información adicional sobre la empresa real que ese está modelando con 
la base de datos. En este capítulo se introduce el concepto de la dependencia funcional. Luego 
se definirán las formas normales en términos de las dependencias funcionales y otros tipos de 
dependencias de datos. 



7.1. PRIMERA FORMA NORMAL 


La primera de las formas normales que se van a estu¬ 
diar, la primera forma normal, impone un requisito 
muy elemental a las relaciones; a diferencia de las demás 
formas normales, no exige información adicional como 
las dependencias funcionales. 

Un dominio es atómico si se considera que los ele¬ 
mentos del dominio son unidades indivisibles. Se dice 
que el esquema de una relación R está en la primera 
forma normal (1FN) si los dominios de todos los atri¬ 
butos de R son atómicos. 

Un conjunto de nombres es un ejemplo de valor no 
atómico. Por ejemplo, si el esquema de la relación 
empleado incluyera el atributo hijos, los elementos de 
cuyo dominio son conjuntos de nombres, el esquema 
no se hallaría en la primera forma normal. 

Los atributos compuestos, como el atributo direc¬ 
ción con sus atributos componentes ccdle y ciudad , tie¬ 
nen también dominios no atómicos. 

Se da por supuesto que los enteros son atómicos, por 
lo que el conjunto de enteros es un dominio atómico; el 
conjunto de todos los conjuntos de enteros es un domi¬ 
nio no atómico. La diferencia estriba en que normal¬ 
mente no se considera que los enteros tengan subpar¬ 
tes, pero sí se considera que los tienen los conjuntos de 
enteros, es decir, los enteros que componen el conjun¬ 
to. Pero lo importante no es lo que sea el propio domi¬ 
nio, sino el modo en que se utilizan los elementos del 
dominio en la base de datos. 

El dominio de todos los enteros no sería atómico si 
se considerara que cada entero es una lista ordenada de 
cifras. 

Como ilustración práctica del punto anterior, consi¬ 
dérese una organización que asigna a los empleados 
números de identificación de la manera siguiente: las 


dos primeras letras especifican el departamento y las 
cuatro cifras restantes son un número único para el 
empleado dentro de ese departamento. Ejemplos de estos 
números pueden ser //V0012 y ELI 127. Estos números 
de identificación pueden dividirse en unidades meno¬ 
res y, por tanto, no son atómicos. Si el esquema de una 
relación tuviera un atributo cuyo dominio consistiera 
en números de identificación codificados como se ha 
indicado, el esquema no se hallaría en la primera forma 
normal. 

Cuando se utilizan estos números de identificación, 
se puede averiguar el departamento de cada emplean¬ 
do escribiendo código que analice la estructura de los 
números de identificación. Ello exige programación adi¬ 
cional y la información queda codificada en el progra¬ 
ma de aplicación en vez de en la base de datos. Surgen 
nuevos problemas si se utilizan estos números de iden¬ 
tificación como claves principales: Cada vez que un 
empleado cambia de departamento hay que cambiar su 
número de identificación, lo que puede constituir una 
tarea difícil, o en su defecto el código que interpreta ese 
número dará un resultado erróneo. 

El empleo de atributos con el valor dado por el con¬ 
junto puede llevar a diseños con almacenamiento de 
datos redundantes, lo que, a su vez, puede dar lugar a 
inconsistencias. Por ejemplo, en lugar de representar la 
relación entre las cuentas y los clientes como una rela¬ 
ción independiente impositor, puede que un diseñador 
de bases de datos esté tentado a almacenar un conjun¬ 
to de titulares con cada cuenta y un conjunto de cuen¬ 
tas con cada cliente. Siempre que se cree una cuenta, o 
se actualice el conjunto de titulares de una cuenta, hay 
que llevar a cabo la actualización en dos lugares; no lle¬ 
var a cabo las dos actualizaciones puede dejar la base 
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de datos en un estado inconsistente. La conservación de 
sólo uno de estos conjuntos evitaría la información repe¬ 
tida, pero complicaría algunas consultas. También es 
más complicado tanto escribir consultas con los atribu¬ 
tos con el valor dado por el conjunto como razonar sobre 
ellos. 

En este capítulo sólo se toman en consideración 
dominios atómicos y se da por supuesto que las rela¬ 
ciones están en la primera forma normal. Aunque no se 
haya mencionado antes la primera forma normal, cuan¬ 
do se introdujo el modelo relacional en el Capítulo 3, 
se afirmó que los valores de los atributos deben ser ató¬ 
micos. 

Algunos tipos de valores no atómicos pueden resul¬ 
tar útiles, aunque deben utilizarse con cuidado. Por ejem¬ 
plo, los atributos con valores compuestos suelen resul¬ 


tar útiles, y los atributos de tipo conjunto también resul¬ 
tan útiles en muchos casos, que es el motivo por el que 
el modelo E-R los soporta. En muchos dominios en los 
que las entidades tienen una estructura compleja, la 
imposición de la representación en la primera forma 
normal representa una carga innecesaria para el pro¬ 
gramador de las aplicaciones, que tiene que escribir 
código para convertir los datos a su forma atómica. Tam¬ 
bién hay sobrecarga en tiempo de ejecución por la con¬ 
versión de los datos a la forma atómica y desde ella. Por 
tanto, el soporte de los valores no atómicos puede resul¬ 
tar muy útil en esos dominios. De hecho, los sistemas 
modernos de bases de datos soportan muchos tipos de 
valores no atómicos, como se verá en los capítulos 8 y 
9. Sin embargo, en este capítulo nos limitaremos a las 
relaciones en la primera forma normal. 


7.2. DIFICULTADES EN EL DISEÑO DE BASES DE DATOS RELACIONALES 


Antes de continuar con el estudio de las formas nor¬ 
males hay que examinar lo que puede salir mal en un 
mal diseño de bases de datos. Entre las propiedades 
indeseables que puede tener un mal diseño están: 

• Repetición de la información 

• Imposibilidad de la representación de determina¬ 
da información 

Estos problemas se estudiarán con ayuda de un diseño 
de base de datos modificado para el ejemplo bancario: 
A diferencia del esquema de relación utilizado en los 
capítulos 3 a 6, supóngase que la información relativa 
a los préstamos se guarda en una sola relación, emprés¬ 
tito , que se define mediante el esquema de relación 

Esquema-empréstito = ( nombre-sucursal, 
ciudad-sucursal, activo, nombre-cliente, 
número-préstamo, importé) 


La Figura 7.1 muestra un ejemplo de la relación emprés¬ 
tito ( esquema-empréstito ). Cada tupia t de la relación 
empréstito tiene el siguiente significado intuitivo: 

• t[activo ] es el volumen de activo de la sucursal 
denominada t[nombre-sucursal]. 

• t[ciudad-sucursal ] es la ciudad en la que se ubica 
la sucursal denominada t[nombre-sucursal ]. 

• t[número-préstamo] es el número asignado al prés¬ 
tamo concedido por la sucursal denominada t[nom- 
bre-sucursal] al cliente llamado t[nombre-cliente]. 

• t[importe] es el importe del préstamo cuyo núme¬ 
ro es t[número-préstamo ]. 

Supóngase que se desea añadir un nuevo préstamo a la 
base de datos. Digamos que el préstamo se lo concede 
la sucursal de Navacerrada a la señora Fernández por 
un importe de 1500 €. Sea el número-préstamo P-31. 


(Navacerrada, Aluche, 1.700.000, Fernández, P-31, 1.500) 


nombre-sucursal 

ciudad-sucursal 

activo 

nombre-cliente 

número-préstamo 

importe 

Centro 

Arganzuela 

9.000.000 

Santos 

P-17 

1.000 

Moralzarzal 

La Granja 

2.100.000 

Gómez 

P-23 

2.000 

Navacerrada 

Aluche 

1.700.000 

López 

P-15 

1.500 

Centro 

Arganzuela 

9.000.000 

Sotoca 

P-14 

1.500 

Becerril 

Aluche 

400.000 

Santos 

P-93 

500 

Collado Mediano 

Aluche 

8.000.000 

Abril 

P-11 

900 

Navas de la Asunción 

Alcalá de Henares 

300.000 

Valdivieso 

P-29 

1.200 

Segovia 

Cerceda 

3.700.000 

López 

P-16 

1.300 

Centro 

Arganzuela 

9.000.000 

González 

P-18 

2.000 

Navacerrada 

Aluche 

1.700.000 

Rodríguez 

P-25 

2.500 

Galapagar 

Arganzuela 

7.100.000 

Amo 

P-10 

2.200 


FIGURA 7.1. Relación empréstito de ejemplo. 
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En el diseño hace falta una tupia con los valores de todos 
los atributos de Esquema-empréstito. Por tanto, hay que 
repetir los datos del activo y de la ciudad de la sucursal 
de Navacerrada y añadir la tupia a la relación emprés¬ 
tito. En general, los datos del activo y de la ciudad deben 
aparecer una vez para cada préstamo concedido por esa 
sucursal. 

La repetición de la información en el diseño alter¬ 
nativo no es deseable. La repetición de la información 
desaprovecha el espacio. Además, complica la actuali¬ 
zación de la base de datos. Supóngase, por ejemplo, que 
el activo de la sucursal de Navacerrada cambia de 
1.700.000 a 1.900.000. Con el diseño original hay que 
modificar una tupia de la relación sucursal. Con el dise¬ 
ño alternativo hay que modificar muchas tupias de la 
relación empréstito. Por tanto, las actualizaciones resul¬ 
tan más costosas con el diseño alternativo que con el 
original. Cuando se lleva a cabo la actualización en la 
base de datos alternativa hay que asegurarse de que se 
actualicen todas las tupias correspondientes a la sucur¬ 
sal de Navacerrada, o la base de datos mostrará dos valo¬ 
res diferentes del activo para esa sucursal. 

Esa observación resulta fundamental para la com¬ 
prensión del motivo por el que el diseño alternativo 
es malo. Se sabe que cada sucursal bancada tiene un 
valor único del activo, por lo que dado el nombre de 
una sucursal se puede identificar de manera única el 
valor del activo. Por otro lado, se sabe que cada sucur¬ 
sal puede conceder muchos préstamos por lo que, dado 
el nombre de una sucursal, no se puede determinar de 
manera única el número de un préstamo. En otras pala¬ 
bras, se dice que se cumple la dependencia funcional 


nombre-sucursal —> activo 

para Esquema-empréstito, pero no se espera que se cum¬ 
pla la dependencia funcional nombre-sucursal —» nú¬ 
mero-préstamo. El hecho de que cada sucursal tenga 
un valor concreto del activo y el de que cada sucursal 
conceda préstamos son independientes y, como se ha 
visto, esos hechos quedan mejor representados en rela¬ 
ciones distintas. Se verá que se pueden utilizar las depen¬ 
dencias funcionales para la especificación formal cuan¬ 
do el diseño de la base de datos es bueno. 

Otro problema del diseño Esquema-empréstito es 
que no se puede representar de manera directa la infor¬ 
mación relativa a cada sucursal ( nombre-sucursal, ciu¬ 
dad-sucursal, activo ) a menos que haya como mínimo 
un préstamo en esa sucursal. Esto se debe a que las tupias 
de la relación empréstito exigen los valores de número- 
préstamo, importe y nombre-cliente. 

Una solución para este problema es introducir los valo¬ 
res nulos, como se hizo para tratar las actualizaciones 
mediante las vistas. Hay que recordar, no obstante, que 
los valores nulos resultan difíciles de manejar, como se 
vio en el Apartado 3.3.4. Si no se desea tratar con los 
valores nulos se puede crear la información sobre cada 
sucursal sólo después de que se formule la primera soli¬ 
citud de préstamo en esa sucursal. Lo que es peor aún, 
habrá que ehminar esa información cuando se hayan paga¬ 
do todos los préstamos. Evidentemente, esta situación no 
resulta deseable ya que, con el diseño original de la base 
de datos, la información sobre la sucursal estaba dispo¬ 
nible independientemente de si se mantenía algún prés¬ 
tamo vivo en la sucursal, y sin recurrir a los valores nulos. 


7.3. DEPENDENCIAS FUNCIONALES 


Las dependencias funcionales desempeñan un papel fun¬ 
damental en la diferenciación entre los buenos diseños 
de bases de datos y los malos. Una dependencia fun¬ 
cional es un tipo de restricción que constituye una gene¬ 
ralización del concepto de clave, como se estudió en los 
capítulos 2 y 3. 

7.3.1. Conceptos básicos 

Las dependencias funcionales son restricciones del con¬ 
junto de relaciones legales. Permiten expresar hechos 
sobre la empresa que se modela con la base de datos. 

En el Capítulo 2 se definió el concepto de supercla- 
ve de la manera siguiente. Sea R el esquema de una rela¬ 
ción. El subconjunto K de R es una superclave de R si, 
en cualquier relación legal r(R), para todos los pares t x 
y t 2 de tupias de r tales que t x * t 2 , t x [AT| * t 2 [AT|. Es 
decir, ningún par de tupias de una relación legal r(R) 
puede tener el mismo valor para el conjunto de atribu¬ 
tos K. 


El concepto de dependencia funcional generaliza la 
noción de superclave. Considérese el esquema de una 
relación R y sean a C R y [] C R. La dependencia fun¬ 
cional 

a-> f 3 

se cumple para el esquema R si, en cualquier relación 
legal r (R), para todos los pares de tupias t¡ y t 2 de r tales 
que t Y [a] = t 2 [a], también ocurre que í, [/>] = t 2 [/!]. 

Empleando la notación para la dependencia funcio¬ 
nal, se dice que K es una superclave de R si K -* R. Es 
decir, K es una superclave si, siempre que t { \ K\ = t 2 [A], 
también se produce que \R \ = t 2 [/?] (es decir, t } = t 2 ). 

Las dependencias funcionales nos permiten expre¬ 
sar las restricciones que no se pueden expresar con las 
superclaves. Considérese el esquema 
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que es una simplificación de Esquema-empréstito, que 
se ha visto anteriormente. El conjunto de dependencias 
funcionales que se espera que se cumplan en este esque¬ 
ma de relación es 

número-préstamo —> importe 
número-préstamo —> nombre-sucursal 

Sin embargo, no se espera que se cumpla la dependen¬ 
cia funcional 

número-préstamo —» nombre-cliente 

ya que, en general, cada préstamo se puede conceder a 
más de un cliente (por ejemplo, a los dos integrantes de 
una pareja marido-esposa). 

Las dependencias funcionales se utilizarán de dos 
maneras: 

1. Para probar las relaciones y ver si son legales 
según un conjunto dado de dependencias funcio¬ 
nales. Si una relación r es legal según el conjun¬ 
to F de dependencias funcionales, se dice que r 

satisface F. 

2. Para especificar las restricciones del conjunto de 
relaciones legales. Así, sólo habrá que preocu¬ 
parse por las relaciones que satisfagan un con¬ 
junto dado de dependencias funcionales. Si uno 
desea restringirse a las relaciones del esquema R 
que satisfagan el conjunto F de dependencias fun¬ 
cionales, se dice que F se cumple en R. 

Considérese la relación r de la Figura 7.2, para ver 
las dependencias funcionales que se satisfacen. Obsér¬ 
vese que se satisface A ^ C. Hay dos tupias que tienen 
un valor para A de a¡. Estas tupias tienen el mismo valor 
para C, por ejemplo, cq. De manera parecida, las dos 
tupias con un valor para A de a 2 tienen el mismo valor 
para C, c 2 . No hay más pares de tupias diferentes que 
tengan el mismo valor para A. Sin embargo, la depen¬ 
dencia funcional C -» A no se satisface. Para verlo, con¬ 
sidérense las tupias q = (a 2 , b 3 , c 2 , d 3 ) y t 2 = {ci 3 , b 3 , c 2 , 
d 4 ). Estas dos tupias tienen los mismos valores para C, 
c 2 , pero tienen valores diferentes para A, a 2 y a 3 , res¬ 
pectivamente. Por tanto, se ha hallado un par de tupias 
q y t 2 tales que q [C ] = t 2 [C], pero q [A] * t 2 [A]. 

r satisface muchas otras dependencias funciona¬ 
les, incluida, por ejemplo, la dependencia funcional 


A 

B 

c 

D 

a, 

ó, 

c, 

di 

a, 

b 2 

c, 

d 2 

a 2 

b 2 

c 2 

d 2 

a 2 

b 3 

c 2 

d 3 

a 3 

^3 

c 2 

d t 


FIGURA 7.2. Relación de ejemplo r. 


AB —* D. Obsérvese que se utiliza AB como abreviatu¬ 
ra de {A,B}, para adecuarnos al uso estándar. Obsérve¬ 
se que no hay ningún par de tupias diferentes q y t 2 tales 
que q \AB ] = t 2 [AB], Por tanto, si q \AB ] = t 2 [AB], debe 
ser que q = t 2 y, por tanto, q \D \ = t 2 [£>]. Así, r satisfa¬ 
ce AB -* D. 

Se dice que algunas dependencias funcionales son 
triviales porque las satisfacen todas las relaciones. Por 
ejemplo, A —* A la satisfacen todas las relaciones que 
impliquen al atributo A. La lectura literal de la defini¬ 
ción de dependencia funcional deja ver que, para todas 
las tupias q y t 2 tales que q [A] = t 2 [A], se cumple que 
q [A] = t 2 [A]. De manera parecida, AB -* A la satisfa¬ 
cen todas las relaciones que impliquen al atributo A. En 
general, una dependencia funcional de la forma a —» /3 
es trivial si ¡3 C a. 

Para distinguir entre los conceptos de que una rela¬ 
ción satisfaga una dependencia y que una dependencia 
se cumpla en un esquema hay que volver al ejemplo del 
banco. Si se considera la relación cliente (en Esquema- 
cliente) de la Figura 7.3, puede verse que se satisface 
calle-cliente —> ciudad-cliente. Sin embargo, se sabe 
que en el mundo real dos ciudades pueden tener calles 
que se llamen igual. Por tanto, resulta posible, en un 
momento dado, tener un ejemplar de la relación clien¬ 
te en la que no se satisfaga calle-cliente —> ciudad-clien¬ 
te. Por consiguiente, no se incluirá calle-cliente —* ciu¬ 
dad-cliente en el conjunto de dependencias funcionales 
que se cumplen en Esquema-cliente. 

En la relación préstamo (de Esquema-préstamo) de 
la Figura 7.4 se puede ver que se satisface la depen¬ 
dencia número-préstamo —* importe. A diferencia del 
caso de ciudad-cliente y calle-cliente de Esquema-clien¬ 
te, se sabe que en la empresa real que se está modelan¬ 
do se exige que cada préstamo tenga un único importe. 
Por tanto, se desea exigir que la relación préstamo satis¬ 
faga siempre número-préstamo —> importe. En otras 
palabras, se exige que la restricción número-préstamo 
—* importe se cumpla en Esquema-préstamo. 

En la relación sucursal de la Figura 7.5 puede verse 
que se satisface nombre-sucursal —> activo, igual que 
ocurre con activo —* nombre-sucursal. Se desea exigir 


nombre-cliente 

calle-cliente 

ciudad-cliente 

Santos 

Mayor 

Peguerinos 

Gómez 

Carretas 

Cerceda 

López 

Mayor 

Peguerinos 

Pérez 

Carretas 

Cerceda 

Rupérez 

Ramblas 

León 

Abril 

Preciados 

Valsaín 

Valdivieso 

Goya 

Vigo 

Fernández 

Jazmín 

León 

González 

Arenal 

La Granja 

Rodríguez 

Yeserías 

Cádiz 

Amo 

Embajadores 

Arganzuela 

Badorrey 

Delicias 

Valsaín 


FIGURA 7.3. La relación cliente. 
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número-préstamo 

nombre-sucursal 

importe 

P-17 

Centro 

1.000 

P-23 

Moralzarzal 

2.000 

P-15 

Navacerrada 

1.500 

P-14 

Centro 

1.500 

P-93 

Becerril 

500 

P-11 

Collado Mediano 

900 

P-29 

Navas de la Asunción 

1.200 

P-16 

Segovia 

1.300 

P-18 

Centro 

2.000 

P-25 

Navacerrada 

2.500 

P-10 

Galapagar 

2.200 


FIGURA 7.4. La relación préstamo. 


nombre-sucursal 

ciudad-sucursal 

activo 

Centro 

Arganzuela 

9.000.000 

Moralzarzal 

La Granja 

2.100.000 

Navacerrada 

Aluche 

1.700.000 

Becerril 

Aluche 

400.000 

Collado Mediano 

Aluche 

8.000.000 

Navas de la Asunción 

Alcalá de Henares 

300.000 

Segovia 

Cerceda 

3.700.000 

Galapagar 

Arganzuela 

7.100.000 


FIGURA 7.5. La relación sucursal. 


que se cumpla nombre-sucursal —> activo en Esquema- 
sucursal. Sin embargo, no se desea exigir que se cum¬ 
pla activo —> nombre-sucursal, ya que es posible tener 
varias sucursales con el mismo valor del activo. 

En lo que viene a continuación se da por supuesto 
que, cuando se diseña una base de datos relacional, se 
enumeran en primer lugar las dependencias funciona¬ 
les que se deben cumplir siempre. En el ejemplo del 
banco, en la lista de dependencias figuran: 

• En Esquema-sucursal: 

nombre-sucursal —» ciudad-sucursal 
nombre-sucursal —* activo 

• En Esquema-cliente'. 

nombre-cliente —» ciudad-cliente 
nombre-cliente —* calle-cliente 

• En Esquema-préstamo'. 

número-préstamo —> importe 
número-préstamo —> nombre-sucursal 

• En Esquema-prestatario'. 

Ninguna dependencia funcional 

• En Esquema-cuenta'. 

número-cuenta —> nombre-sucursal 
número-cuenta —> saldo 

• En Esquemci-impositor. 

Ninguna dependencia funcional 

7.3.2. Cierre de un conjunto de dependencias 
funcionales 

No es suficiente considerar el conjunto dado de depen¬ 
dencias funcionales. También hay que considerar todas 


las dependencias funcionales que se cumplen. Se verá 
que, dado un conjunto F de dependencias funcionales, 
se puede probar que se cumplen otras dependencias fun¬ 
cionales determinadas. Se dice que esas dependencias 
funcionales están «implicadas lógicamente» por F. 

De manera más formal, dado un esquema relacional 
R, una dependencia funcional/de R está implicada lógi¬ 
camente por un conjunto de dependencias funcionales 
F de R si cada ejemplar de la relación r(R) que satisfa¬ 
ce F satisface también/. 

Supóngase que se tiene un esquema de relación R = 
(A, B, C, G, H, /) y el conjunto de dependencias fun¬ 
cionales 

A^B 
A^C 
CG -» H 
CG -* I 
B — II 

La dependencia funcional 

A^H 

está implicada lógicamente. Es decir, se puede demos¬ 
trar que, siempre que el conjunto dado de dependencias 
funcionales se cumple en una relación, en la relación 
también se debe cumplir A^> H. Supóngase que /j y t 2 
son tupias tales que 

h [A] = t 2 [A] 

Como se tiene que A —> B, se deduce de la definición 
de dependencia funcional que 

h [ 5 ] = 1 2 [ B] 

Entonces, como se tiene que B —* H, se deduce de la 
definición de dependencia funcional que 

h {H\ = t 2 [H] 

Por tanto, se ha demostrado que, siempre que f, y t 2 
sean tupias tales que / [A] = t 2 [A], debe ocurrir que 
t j [//] = t 2 [//]. Pero ésa es exactamente la definición 
de A -> H. 

Sea F un conjunto de dependencias funcionales. El 
cierre de F, denotado por F + , es el conjunto de todas 
las dependencias funcionales implicadas lógicamente 
en F. Dado F, se puede calcular F + directamente a par¬ 
tir de la definición formal de dependencia funcional. Si 
F fuera de gran tamaño, este proceso sería prolongado 
y difícil. Este cálculo de F + requiere argumentos del 
tipo que se acaba de utilizar para demostrar que A ^ H 
está en el cierre del conjunto de ejemplo de dependen¬ 
cias. 

Los axiomas, o reglas de inferencia, proporcionan una 
técnica más sencilla para el razonamiento sobre las depen- 
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dencias funcionales. En las reglas que se ofrecen a con¬ 
tinuación se utilizan las letras griegas (a, ¡3, y, ...) para 
los conjuntos de atributos y las letras latinas mayúsculas 
desde el comienzo del alfabeto para los atributos indivi¬ 
duales. Se utiliza ab para denotar a U ¡3. 

Se pueden utilizar las tres reglas siguientes para hallar 
las dependencias funcionales implicadas lógicamente. 
Aplicando estas reglas repetidamente , se puede hallar 
todo F + , dado F. Este conjunto de reglas se denomina 
axiomas de Armstrong en honor de la persona que las 
propuso por primera vez. 

• Regla de la reflexividad. Si a es un conjunto de 
atributos y ¡3 C a, entonces se cumple que a —* /í. 

• Regla de la aumentatividad. Si se cumple que 
a —> ¡3 y y es un conjunto de atributos, entonces se 
cumple que ya —> y/3. 

• Regla de la transitividad. Si se cumple que a —> ¡3 
y también se cumple que /} —» y, entonces se cum¬ 
ple que a-* y. 

Los axiomas de Armstrong son correctos porque no 
generan dependencias funcionales incorrectas. Son com¬ 
pletos, porque, para un conjunto dado F de dependen¬ 
cias funcionales, permiten generar todo F + . Las notas 
bibliográficas proporcionan referencias de las pruebas 
de su corrección y de su completitud. 

Aunque los axiomas de Armstrong son completos, 
resulta difícil utilizarlos directamente para el cálculo de 
F + . Para simplificar más las cosas se relacionan unas 
reglas adicionales. Resulta posible utilizar los axiomas 
de Armstrong para probar que estas reglas son correc¬ 
tas (véanse los ejercicios 7.8, 7.9 y 7.10). 

• Regla de la unión. Si se cumple que a -» /3 y que 
a —> y, entonces se cumple que a —> ¡3y. 

• Regla de la descomposición. Si se cumple que 
a —> ¡3y, entonces se cumple que a —* ¡3 y que 
a -> y. 

• Regla de la pseudotransitividad. Si se cumple 
que a —* ¡3 y que y¡3 —> <5, entonces se cumple que 
ay -> d. 

Apliquemos ahora las reglas al ejemplo del esquema 
R = (A, B, C, G, //, /) y el conjunto F de dependencias 
funcionales {A ^ B,A—> C, CG —> H, CG —*I,B—*H}. 
A continuación se relacionan varios miembros de F + : 

• A -» H. Dado que se cumplen A -> B y B -> H, se 
aplica la regla de transitividad. Obsérvese que 
resultaba mucho más sencillo emplear los axiomas 
de Armstrong para demostrar que se cumple que 
A -» Fl que deducirlo directamente a partir de las 
definiciones, como se ha hecho anteriormente en 
este apartado. 

• CG —* FU. Dado que CG —» H y CG —> /, la regla 
de unión implica que CG —> III. 


• AG -> I. Dado que A ^ C y CG -* /, la regla 
de pseudotransitividad implica que se cumple que 
AG -* I. 

Otra manera de hallar que se cumple que AG -* I 
es la siguiente. Se utiliza la regla de aumentatividad en 
A -» C para inferir que AG -* CG. Aplicando la regla 
de transitividad a esta dependencia y CG -* /, se infie¬ 
re que AG —* /. 

La Ligura 7.6 muestra un procedimiento que demues¬ 
tra formalmente el modo de utilizar los axiomas de 
Armstrong para calcular F + . En este procedimiento, 
cuando se añade una dependencia funcional a F + , pue¬ 
de que ya esté presente y, en ese caso, no hay ninguna 
modificación en F + . También se verá una manera alter¬ 
nativa de calcular F + en el Apartado 7.3.3. 

Los términos a la derecha y a la izquierda de una 
dependencia funcional son subconjuntos de R. Dado 
que un conjunto de tamaño n tiene 2" subconjuntos, hay 
un total de 2 x 2” = 2" +1 dependencias funcionales posi¬ 
bles, donde n es el número de atributos de R. Cada ite¬ 
ración del bucle repeat del procedimiento, salvo la últi¬ 
ma, añade como mínimo una dependencia funcional a 
F + . Por tanto, se garantiza que el procedimiento se ter¬ 
mine. 

7.3.3. Cierre de un conjunto de atributos 

Para comprobar si un conjunto a es una superclave hay 
que diseñar un algoritmo para el cálculo del conjunto 
de atributos determinados funcionalmente por a. Una 
manera de hacerlo es calcular F + , tomar todas las depen¬ 
dencias funcionales con a como término de la izquier¬ 
da y tomar la unión de los términos de la derecha de 
todas esas dependencias. Sin embargo, hacer esto pue¬ 
de resultar costoso, ya que F + puede ser de gran ta¬ 
maño. 

El algoritmo eficiente para calcular el conjunto de 
atributos determinados funcionalmente por a no sólo 
resulta útil para comprobar si a es una superclave, sino 
también para otras tareas, como se verá más adelante 
en este apartado. 

Sea a un conjunto de atributos. Al conjunto de todos 
los atributos determinados funcionalmente por a bajo 
un conjunto F de dependencias funcionales se le deno¬ 
mina cierre de a bajo F\ se denota mediante a + . La 
Ligura 7.7 muestra un algoritmo, escrito en pseudocó- 

F* = F 

repeat 

for each dependencia funcional f de F + 

aplicar las reglas de reflexividad y de aumentatividad a f 
añadir las dependencias funcionales resultantes a F* 
for each pareja de dependencias funcionales f, y f 2 de F* 
if y f 2 pueden combinarse mediante la transitividad 
añadir la dependencia funcional resultante a F + 
until F* no cambie más 

FIGURA 7.6. Procedimiento para calcular F + . 
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resultado := a; 

while (cambios en resultado) do 

for each dependencia funcional p -» yin Fdo 

begin 

if p C resultado then resultado := resultado U y; 

end 

FIGURA 7.7. Algoritmo para el cálculo de a + , el cierre de a 
bajo F. 

digo, para calcular a + . La entrada es un conjunto F de 
dependencias funcionales y el conjunto a de atributos. 
La salida se almacena en la variable resultado. 

Para ilustrar el modo en que trabaja el algoritmo se 
utilizará para calcular (AG) + con las dependencias fun¬ 
cionales definidas en el Apartado 7.3.2. Se comienza 
con resultado = AG. La primera vez que se ejecuta el 
bucle while para comprobar cada dependencia funcio¬ 
nal se halla que 

• A —» B hace que se incluya B en resultado. Para 
ver este hecho, se observa que A —* B se halla en 
F y AG resultado (que es AG), por lo que resul¬ 
tado := resultado U B. 

• A—*C hace que resultado se transforme en ABCG. 

• CG —> Fl hace que resultado se transforme en 
ABCGH. 

• CG —> I hace que resultado se transforme en 
ABCGHI. 

La segunda vez que se ejecuta el bucle while no se aña¬ 
den atributos nuevos a resultado, y se termina el algo¬ 
ritmo. 

Veamos ahora el motivo por el que el algoritmo de 
la Figura 7.7 es correcto. El primer paso es correcto, ya 
que a^ase cumple siempre (por la regla de reflexi- 
vidad). Se asegura que, para cualquier subconjunto (3 de 
resultado, a—> ¡3. Dado que se inicia el bucle while con 
a —* resultado como cierto, sólo se puede añadir y a 
resultado si ¡3 C resultado y /3 —» y. Pero, entonces, resul¬ 
tado -* ¡3 por la regla de reflexividad, por lo que a —> ¡3 
por transitividad. Otra aplicación de la transitividad 
demuestra que a —> y (utilizando a —> (3 y ¡3 —> y). La 
regla de la unión implica que a —> resultado U y, por 
lo que a determina funcionalmente cualquier resultado 
nuevo generado en el bucle while. Por tanto, cualquier 
atributo devuelto por el algoritmo se halla en a + . 

Resulta sencillo ver que el algoritmo halla todo a + . 
Si hay un atributo de a + que no se halle todavía en resul¬ 
tado, debe haber una dependencia funcional ¡3 —* y para 
la que ¡3 C resultado y, como mínimo, un atributo de y 
no se halla en resultado. 

Resulta que, en el peor de los casos, este algoritmo 
puede tardar un tiempo proporcional al cuadrado del 
tamaño de F. Hay un algoritmo más rápido (aunque lige¬ 
ramente más complejo) que se ejecuta en un tiempo pro¬ 
porcional al tamaño de F; este algoritmo se presenta 
como parte del Ejercicio 7.14. 


Hay varios usos para el algoritmo de cierre de atri¬ 
butos: 

• Comprobar si a es una superclave, se calcula a + y 
se comprueba si a + contiene todos los atributos de 
R. 

• Se puede comprobar si se cumple la dependencia 
funcional a —* ¡3 (o, en otras palabras, si se halla 
en F + ), comprobando si /} C ct. Es decir, se cal¬ 
cula a + empleando el cierre de los atributos y lue¬ 
go se comprueba si contiene a ¡3. Esta prueba resul¬ 
ta especialmente útil, como se verá más adelante 
en este capítulo. 

• Ofrece una manera alternativa de calcular F + : para 
cada y C R se halla el cierre y + y, para cada S C y + , 
se genera una dependencia funcional y —> S. 

7.3.4. Recubrimiento canónico 

Supóngase que se tiene un conjunto de dependencias 
funcionales F de un esquema de relación. Siempre que 
un usuario lleve a cabo una actualización de la relación 
el sistema de bases de datos debe asegurarse de que la 
actualización no viole ninguna dependencia funcional, 
es decir, que se satisfagan todas las dependencias fun¬ 
cionales de F en el nuevo estado de la base de datos. 

El sistema debe retroceder la actualización si viola 
alguna dependencia funcional del conjunto F. 

Se puede reducir el esfuerzo empleado en la com¬ 
probación de las violaciones comprobando un conjun¬ 
to simplificado de dependencias funcionales que tenga 
el mismo cierre que el conjunto dado. Cualquier base 
de datos que satisfaga el conjunto simplificado de depen¬ 
dencias funcionales satisfará también el conjunto ori¬ 
ginal y viceversa, ya que los dos conjuntos tienen el 
mismo cierre. Sin embargo, el conjunto simplificado 
resulta más sencillo de comprobar. En breve se verá el 
modo en que se puede crear el conjunto simplificado. 
Antes, hacen falta algunas definiciones. 

Se dice que un atributo de una dependencia funcio¬ 
nal es raro si se puede eliminar sin modificar el cierre 
del conjunto de dependencias funcionales. La defini¬ 
ción formal de los atributos raros es la siguiente. Con¬ 
sidérese un conjunto F de dependencias funcionales y 
la dependencia funcional a —> fi de F. 

• El atributo A es raro enasiAGayf implica lógi¬ 
camente a (F - {a -> ¡3}) U {(a - A) -> ¡3}. 

• El atributo A es raro en ¡3 si A G ¡3 y el conjunto 
de dependencias funcionales (F - {a -* ¡3}) U 
{a -> (¡3- A)} implica lógicamente a F. 

Por ejemplo, supóngase que se tienen las dependen¬ 
cias funcionales AB —> C y A —* C de F. Entonces, B es 
raro en AB —> C. Otro ejemplo más: supóngase que se tie¬ 
nen las dependencias funcionales AB -* CD y A -* C de 
F. Entonces, C será raro en el lado derecho de AB -* CD. 
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Hay que prestar atención a la dirección de las im¬ 
plicaciones cuando se utiliza la definición de los atri¬ 
butos raros: si se intercambian el lado derecho y el 
izquierdo la implicación se cumplirá siempre. Es decir, 
(F- {a -» ¡3}) U {(a-A) -> ¡3} siempre implica lógi¬ 
camente a F, y también F implica siempre lógicamen¬ 
te a (F - {a -> ¡3}) U {a -» (¡3 - A)} 

He aquí el modo de comprobar de manera eficiente 
si un atributo es raro. Sea R el esquema de la relación 
y F el conjunto dado de dependencias funcionales que 
se cumplen en R. 

Considérese el atributo A de la dependencia ¡3. 

• Si A El ¡3, para comprobar si A es raro hay que con¬ 
siderar el conjunto 

F'=(F-{a-j8})U{a-*(j8-A)} 
y comprobar si a -* A puede inferirse a partir de 
F'. Para ello hay que calcular a + (el cierre de a) 
bajo F'; si a + incluye a A, entonces A es raro en ¡3. 

• Si A G a, para comprobar si A es raro, sea y = a - 
{A}, hay que comprobar si se puede inferir que 
y -> ¡3 a partir de F. Para ello hay que calcular y + 
(el cierre de y) bajo F; si y + incluye todos los atri¬ 
butos de ¡3 , entonces A es raro en a. 

Por ejemplo, supóngase que F contiene AB —> CD, 
A—*F y E —> C. Para comprobar si C es raro en AB ^ CD, 
hay que calcular el cierre de los atributos de AB bajo 
F' = {AB -*D, A ^ E y E ^ C}. El cierre es ABCDE, 
que incluye a CD, por lo que se infiere que C es raro. 

El recubrimiento canónico F c de F es un conjunto 
de dependencias tales que F implica lógicamente todas 
las dependencias de F c y F c implica lógicamente todas 
las dependencias de F. Además, F c debe tener las pro¬ 
piedades siguientes: 

• Ninguna dependencia funcional de F c contiene atri¬ 
butos raros. 

• El lado izquierdo de cada dependencia funcional 
de F c es único. Es decir, no hay dos dependencias 
a \ A Y a 2 ~* Pi de F c tales que a¡ = a 2 . 

El recubrimiento canónico del conjunto de depen¬ 
dencias funcionales F puede calcularse como se mues¬ 
tra en la Figura 7.8. Es importante destacar que, cuan¬ 
do se comprueba si un atributo es raro, la comprobación 
utiliza las dependencias del valor actual de F c , y no las 


dependencias de F. Si una dependencia funcional sólo 
contiene un atributo en su lado derecho, por ejemplo, 
A —» C, y se descubre que ese atributo es raro, se obtie¬ 
ne una dependencia funcional con el lado derecho vacío. 
Hay que eliminar estas dependencias funcionales. 

Se puede demostrar que el recubrimiento canónico 
de F, F c , tiene el mismo cierre que F; por tanto, la com¬ 
probación de si se satisface F c es equivalente a la com¬ 
probación de si se satisface F. Sin embargo, F c es míni¬ 
mo en un cierto sentido: no contiene atributos raros, y 
combina las dependencias funcionales con el lado 
izquierdo idéntico. Resulta más económico comprobar 
F c que comprobar el propio F. 

Considérese el siguiente conjunto F de dependen¬ 
cias funcionales para el esquema ( A,B,C ): 

A —» BC 
B^C 
A^B 
AB —> C 

Calcúlese el recubrimiento canónico de F. 

• Hay dos dependencias funcionales con el mismo 
conjunto de atributos a la izquierda de la flecha: 

A —» BC 
A^B 

Estas dependencias funcionales se combinan en 
A —> BC. 

• A es raro en AB —> C porque F implica lógicamente 
a (F - {AB -* C}) U [B —* C}. Esta aseveración 
es cierta porque B ^ C ya se halla en el conjunto 
de dependencias funcionales. 

• C es raro en A -> BC, ya que A -> BC está impli¬ 
cada lógicamente por A -* B y B -» C. 

Por tanto, el recubrimiento canónico es: 

A^B 
B — C 

Dado un conjunto F de dependencias funcionales, 
puede que toda una dependencia funcional del con¬ 
junto sea rara, en el sentido de que su eliminación no 
modifica el cierre de F. Se puede demostrar que el 
recubrimiento canónico F c de F no contiene esa depen¬ 
dencia funcional rara. Supóngase que, por el contra- 


Fc= F 

repeat 

Utilizar la regla de unión para sustituir las dependencias de F c de la forma 

fe con a, -» fe fe. 

Hallar una dependencia funcional a -» /8 de F c con un atributo raro en a o en p. 

/* Nota: la comprobación de los atributos raros se lleva a cabo empleando F c , no F*/ 
Si se halla algún atributo raro, hay que eliminarlo dea^/i. 
until F c ya no cambie. 

FIGURA 7.8. Cálculo del recubrimiento canónico. 
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rio, existiera esa dependencia rara en F c . Los atribu¬ 
tos del lado derecho de la dependencia serían raros, lo 
que no es posible por la definición de los recubri¬ 
mientos canónicos. 

Puede que el recubrimiento canónico no sea único. 
Por ejemplo, considérese el conjunto de dependencias 
funcionales F = {A^ BC, B —> AC yC^ AB}. Si se 
aplica la prueba de rareza aA ^ BC se descubre que 
tanto B como C son raros bajo F. Sin embargo, sería 
incorrecto eliminarlos a los dos. El algoritmo para hallar 
el recubrimiento canónico selecciona uno de ellos y lo 
elimina. Entonces, 

1. Si se elimina C, se obtiene el conjunto F' = 
(A B, B -* AC yC^ AS}. Ahora B ya no es 


raro en el lado derecho de A -» S bajo F'. 
Siguiendo con el algoritmo se descubre que A 
y B son raros en el lado derecho de C -» AS, lo 
que genera dos recubrimientos canónicos, 
P c ={A^S,S^CyC^A}y 
F c ={A^B,B^ACyC^ B}. 

2. Si se elimina S, se obtiene el conjunto (A —> C, 
S -> AC y C -* AS}. Este caso es simétrico al 
anterior, y genera dos recubrimientos canónicos, 
F c = (A — C, C — S y S — A} y 
F C = {A^> C,B ^ Cy C ^ AB}. 

Como ejercicio el lector debe intentar hallar otro recu¬ 
brimiento canónico de F. 


7.4. DESCOMPOSICIÓN 


El mal diseño del Apartado 7.2 sugiere que se deben 
descomponer los esquemas de relación que tienen 
muchos atributos en varios esquemas con menos atri¬ 
butos. Una descomposición poco cuidadosa, no obs¬ 
tante, puede llevar a otra modalidad de mal diseño. 

Considérese un diseño alternativo en el que se des¬ 
compone Esquema-empréstito en los dos esquemas 
siguientes: 

Esquema-sucursal-cliente = ( nombre-sucursal, 
ciudad-sucursal, activo, nombre-cliente) 
Esquema-cliente-préstamo = ( nombre-cliente, 
número-préstamo, importé) 

Empleando la relación empréstito de la Figura 7.1 se 
crean las relaciones nuevas sucursal-cliente ( Esquema- 
sucursal-cliente) y cliente-préstamo ( Esquema-cliente- 
préstamo ): 

sucursal-cliente = n nom b re . sucursa [ t ciudad-sucursal, 
activo, nombre-cliente ( empréstito) 
cliente-préstamo = ^ nombre _ cliente¡ númew - P réstamo, 
importe ( empréstito) 

Las Figuras 7.9 y 7.10, respectivamente, muestran las 
relaciones sucursal-cliente y nombre-cliente resultantes. 

Por supuesto, hay casos en los que hace falta recons¬ 
truir la relación préstamo. Por ejemplo, supóngase que 
se desea hallar todas las sucursales que tienen présta¬ 
mos con importes inferiores a 1000 €. Ninguna rela¬ 
ción de la base de datos alternativa contiene esos datos. 
Hay que reconstruir la relación empréstito. Parece que 
se puede hacer escribiendo 

sucursal-cliente XI cliente-préstamo 

La Figura 7.11 muestra el resultado de calcular sucur¬ 
sal-cliente X préstamo-cliente. Cuando se compara 


nombre-sucursal 

ciudad- 

sucursal 

activo 

nombre- 

cliente 

Centro 

Arganzuela 

9.000.000 

Santos 

Moralzarzal 

La Granja 

2.100.000 

Gómez 

Navacerrada 

Aluche 

1.700.000 

López 

Centro 

Arganzuela 

9.000.000 

Sotoca 

Becerril 

Aluche 

400.000 

Santos 

Collado Mediano 

Aluche 

8.000.000 

Abril 

Navas de 

Alcalá 

300.000 

Valdivieso 

la Asunción 

de Henares 



Segovia 

Cerceda 

3.700.000 

López 

Centro 

Arganzuela 

9.000.000 

González 

Navacerrada 

Aluche 

1.700.000 

Rodríguez 

Galapagar 

Arganzuela 

7.100.000 

Amo 


FIGURA 7.9. La relación sucursal-cliente. 


esta relación con la relación empréstito con la cual 
comenzamos (Figura 7.1) se aprecia una diferencia: 
aunque cada tupia que aparece en empréstito aparece 
también en sucursal-cliente X préstamo-cliente, hay 
tupias de sucursal-cliente X préstamo-cliente que no 


nombre-cliente 

número-préstamo 

importe 

Santos 

P-17 

1.000 

Gómez 

P-23 

2.000 

López 

P-15 

1.500 

Sotoca 

P-14 

1.500 

Santos 

P-93 

500 

Abril 

P-11 

900 

Valdivieso 

P-29 

1.200 

López 

P-16 

1.300 

González 

P-18 

2.000 

Rodríguez 

P-25 

2.500 

Amo 

P-10 

2.200 


FIGURA 7.10. La relación cliente-préstamo. 
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nombre-sucursal 

ciudad-sucursal 

activo 

nombre-cliente 

número-préstamo 

importe 

Centro 

Arganzuela 

9.000.000 

Santos 

P-17 

1.000 

Centro 

Arganzuela 

9.000.000 

Santos 

P-93 

500 

Moralzarzal 

La Granja 

2.100.000 

Gómez 

P-23 

2.000 

Navacerrada 

Aluche 

1.700.000 

López 

P-15 

1.500 

Navacerrada 

Aluche 

1.700.000 

López 

P-16 

1.300 

Centro 

Arganzuela 

9.000.000 

Sotoca 

P-14 

1.500 

Becerril 

Aluche 

400.000 

Santos 

P-17 

1.000 

Becerril 

Aluche 

400.000 

Santos 

P-93 

500 

Collado Mediano 

Aluche 

8.000.000 

Abril 

P-11 

900 

Navas de la Asunción 

Alcalá de Henares 

300.000 

Valdivieso 

P-29 

1.200 

Segovia 

Cerceda 

3.700.000 

López 

P-15 

1.500 

Segovia 

Cerceda 

3.700.000 

López 

P-16 

1.300 

Centro 

Arganzuela 

9.000.000 

González 

P-18 

2.000 

Navacerrada 

Aluche 

1.700.000 

Rodríguez 

P-25 

2.500 

Galapagar 

Arganzuela 

7.100.000 

Amo 

P-10 

2.200 


FIGURA 7.11. La relación sucursal-cliente XI cliente-préstamo. 


están en empréstito. En el ejemplo, sucursal-cliente 
X préstamo-cliente tiene las siguientes tupias adi¬ 
cionales: 

(Centro, Arganzuela, 9.000.000, Santos, P-93, 500) 
(Navacerrada, Aluche, 1.700.000, López, P-16, 1.300) 
(Becerril, Aluche, 400.000, Santos, P-17, 1.000) 
(Segovia, Cerceda, 3.700.000, López, P-15, 1.500) 

Considérese la consulta «Hallar todas las sucursales que 
han concedido un préstamo por un importe inferior a 
1.500 €». Si se vuelve a la Ligura 7.1 se observa que 
las únicas sucursales con créditos con importe inferior 
a 1.500 € son Becerril y Collado Mediano. Sin embar¬ 
go, al aplicar la expresión 

n nombre-sucursal (°importe < 1.000 ( SUCUrsal-clieilte 
X préstamo-cliente )) 

obtenemos los nombres de tres sucursales: Becerril, 
Collado Mediano y Centro. 

Un examen más detenido de este ejemplo mues¬ 
tra el motivo. Si resulta que un cliente tiene varios 
préstamos de diferentes sucursales, no se puede decir 
el préstamo que pertenece a cada sucursal. Por lo tan¬ 
to, al reunir sucursal-cliente y cliente-préstamo, no 
sólo se obtienen las tupias que se tenía originaria¬ 
mente en empréstito, sino también varias tupias adi¬ 
cionales. Aunque se tengan más tupias en sucursal- 
cliente XI cliente-préstamo, realmente se tiene menos 
información. Ya no es posible, en general, represen¬ 
tar en la base de datos la información de los clientes 
que tienen concedidos préstamos en cada sucursal. 
Debido a esta pérdida de información se dice que la 
descomposición de Esquema-empréstito en Esque¬ 
ma-sucursal-cliente y Esquema-cliente-préstamo es 
una descomposición con pérdida, o una descom¬ 


posición de reunión con pérdida. Una descomposi¬ 
ción que no es una descomposición con pérdida es 
una descomposición de reunión sin pérdida. Que¬ 
da claro con este ejemplo que una descomposición 
de reunión con pérdida supone, en general, un mal 
diseño de base de datos. 

Es interesante averiguar el motivo por el que la des¬ 
composición es una descomposición con pérdida. Hay 
un atributo en común entre Esquema-cliente-sucursal 
y Esquema-cliente-préstamo: 

Esquema-sucursal-cliente Í~1 Esquema-cliente-préstamo 
= {nombre-cliente} 

El único modo de que se pueda representarse una rela¬ 
ción entre, por ejemplo, número-préstamo y nombre- 
sucursal es mediante nombre-cliente. Esta representa¬ 
ción no resulta adecuada porque puede que un cliente 
tenga concedidos varios préstamos, pero esos présta¬ 
mos no tienen que haberse obtenido necesariamente de 
la misma sucursal. 

Considérese otro diseño alternativo en el que se des¬ 
compone Esquema-empréstito en los dos esquemas 
siguientes: 

Esquema-sucursal = ( nombre-sucursal , 
ciudad-sucursal, activo) 

Esquema-info-préstamo = ( nombre-sucursal, 
nombre-cliente, número-préstamo, importe ) 

Hay un atributo en común entre estos dos esquemas: 

Esquema-sucursal-préstamo Cl Esquema-cliente- 
préstamo = {nombre-sucursal} 

Por lo tanto, el único modo de poder representar una rela¬ 
ción entre, por ejemplo, nombre-cliente y activo es 
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mediante nombre-sucursal. La diferencia entre este ejem¬ 
plo y el anterior es que el activo de una sucursal es el 
mismo, independientemente del cliente al que se haga 
referencia, mientras que la sucursal prestamista sí depen¬ 
de del cliente al que se haga referencia. Para un valor 
dado de nombre-sucursal dado, hay exactamente un valor 
de activo y un valor de ciudad-sucursal, mientras que 
no se puede hacer una afirmación parecida para nombre- 
cliente. Es decir, se cumple la dependencia funcional: 

nombre-sucursal —> activo ciudad-sucursal 

pero nombre-cliente no determina funcionalmente a 
número-préstamo. 

El concepto de reunión sin pérdida resulta funda¬ 
mental para gran parte del diseño de bases de datos rela¬ 
ciónales. Por lo tanto, se volverán a formular los ejem¬ 
plos anteriores de manera más concisa y formal. Sea R 
un esquema de relación. Un conjunto de esquemas de 
relación {R { , R 2 , ..., R n } es una descomposición de R si 

R = R l UR 2 U ... U R n 

Es decir, {R { , R 2 , ..., R n } es una descomposición de R 
si, para i = 1, 2,..., n, cada R¡e s un subconjunto de R y 
cada atributo de R aparece en al menos un R¡. 

Sea r una relación del esquema R y r¡ = [ [ A . (/) para 
i = 1, 2,..., n. Es decir, {r u r 2 ,..., r n } es la base de datos 
que resulta de descomponer R en {R¡, R 2 ,..., R,,}. Siem¬ 
pre se cumple que 

r C rj IX r 2 Xl ... M r n 

Para comprobar que esta afirmación es cierta considére¬ 
se una tupia t de la relación r. Cuando se calculan las rela¬ 
ciones r v r 2 , ..., r n , la tupia t da lugar a una tupia t¡ en 
cada r¡, i = 1,2, , n. Estas n tupias se combinan para 

regenerar t cuando se calcula r ] x r 2 x • • • X r n . Los 
detalles se dejan para completarlos como ejercicio. Por 
tanto, cada tupia de r aparece enq M r 2 X ... X r n . 

En general, r * r x X r 2 X • • • X r n . Para mostrarlo 
consideremos el ejemplo anterior, en el que 


• n = 2. 

• R = Esquema-empréstito. 

• R¡ = Esquema-sucursal-cliente. 

• R 2 = Esquema-cliente-préstamo 

• /' = la relación mostrada en la Figura 7.1. 

• r l = la relación mostrada en la Figura 7.9. 

• r 2 = la relación mostrada en la Figura 7.10. 

• M r 2 = la relación mostrada en la Figura 7.11. 

Obsérvese que las relaciones de las Figuras 7.1 y 7.11 
no son iguales. 

Para tener una descomposición de reunión sin pér¬ 
dida hay que imponer restricciones en el conjunto de 
las relaciones posibles. Se descubrió que la descompo¬ 
sición de Esquema-empréstito en Esquema-sucursal y 
Esquema-info-préstamo era sin pérdida porque se cum¬ 
ple la dependencia funcional 

nombre-sucursal —* ciudad-sucursal activo 
en Esquema-sucursal. 

Más adelante en este capítulo se introducirán otras res¬ 
tricciones distintas de las dependencias funcionales. Se 
dice que una relación es legal si satisface todas las reglas, 
o restricciones, que se hayan impuesto en la base de datos. 

Sea C un conjunto de restricciones de la base de datos 
y R un esquema de relación. Una descomposición 
{R { ,R 2 ,..., R„} de R es una descomposición de reunión 
sin pérdida si, para todas las relaciones r del esquema 
R que son legales bajo C 

r = IL, to M ru W M - I* n«„ (r) 

En los siguientes apartados se mostrará el modo de 
comprobar si una descomposición es una descomposición 
de reunión sin pérdida. La parte principal de este capítu¬ 
lo trata del problema de la especificación de restricciones 
para las bases de datos y del modo de obtener descom¬ 
posiciones de reunión sin pérdida que eviten los incon¬ 
venientes representados en los ejemplos de malos dise¬ 
ños de bases de datos que se han visto en este apartado. 


7.5. PROPIEDADES DESEABLES DE LA DESCOMPOSICIÓN 


Se puede utilizar un conjunto dado de dependencias fun¬ 
cionales para diseñar una base de datos relacional en la 
que no se halle presente la mayor parte de las propie¬ 
dades no deseables estudiadas en el Apartado 7.2. Cuan¬ 
do se diseñan estos sistemas puede hacerse necesaria la 
descomposición de una relación en varias relaciones de 
menor tamaño. 

En este apartado se describen las propiedades desea¬ 
bles de las descomposiciones de los esquemas relacióna¬ 
les. En apartados posteriores se describen maneras con¬ 


cretas de descomponer un esquema relacional para obte¬ 
ner las propiedades deseadas. Estos conceptos se ilustran 
con el esquema Esquema-empréstito del Apartado 7.2: 

Esquema-empréstito = ( nombre-sucursal, 
ciudad-sucursal, activo, nombre-cliente, 
número-préstamo, importe ) 

El conjunto F de dependencias funcionales que se exi¬ 
ge que se cumplan en Esquema-empréstito es 
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nombre-sucursal —> ciudad-sucursal activo 
número-préstamo —> importe nombre-sucursal 

Como se estudió en el Apartado 7.2, Esquema- 
empréstito es un ejemplo de un mal diseño de base de 
datos. Supóngase que se descompone en las tres rela¬ 
ciones siguientes: 

Esquema-sucursal - ( nombre-sucursal, 
ciudad-sucursal, activo) 

Esquema-préstamo = ( número-préstamo, 
nombre-sucursal, importe) 
Esquema-prestatario = ( nombre-cliente, 
número-préstamo ) 

Puede afirmarse que esta descomposición tiene varias 
propiedades deseables que se estudiarán a continuación. 
Obsérvese que estos tres esquemas de relación son pre¬ 
cisamente los que se utilizaron anteriormente en los 
capítulos 3 a 5. 

7.5.1. Descomposición de reunión sin pérdida 

En el Apartado 7.4 se argüyó que, al descomponer una 
relación en varias relaciones de menor tamaño, resulta 
fundamental que la descomposición sea una descom¬ 
posición sin pérdida. Se puede afirmar que la descom¬ 
posición del Apartado 7.5 es realmente una descompo¬ 
sición sin pérdida. Para demostrar esta afirmación antes 
hay que presentar un criterio para determinar si una des¬ 
composición es una descomposición con pérdida. 

Sea R un esquema de relación, y sea F un conjunto 
de dependencias funcionales de R. R¡ y R 2 forman una 
descomposición de R. Esta descomposición es una des¬ 
composición de reunión sin pérdida de R si al menos 
una de las siguientes dependencias se halla en F + : 

• /?, n R 2 -> R¡ 

• R { íl R 2 —> R 2 

En otras palabras, si If D R 2 forma una superclave de 
R j o de R 2 , la descomposición de R es una descompo¬ 
sición de reunión sin pérdida. Se puede utilizar el cie¬ 
rre de los atributos para comprobar de manera eficien¬ 
te la existencia de superclaves, como ya se ha visto. 

Ahora se demostrará que la descomposición de 
Esquema-empréstito es una descomposición de reunión 
sin pérdida mostrando una secuencia de pasos que gene¬ 
ran la descomposición. Para empezar se descompone 
Esquema-empréstito en dos esquemas: 

Esquema-sucursal = ( nombre-sucursal, 
ciudad-sucursal, activo) 
Esquema-info-préstamo = ( nombre-sucursal, 
nombre-cliente, número-préstamo, importe) 

Dado que nombre-sucursal —> ciudad-sucursal activo, 
la regla de la aumentatividad para las dependencias fun¬ 
cionales (Apartado 7.3.2) implica que 


nombre-sucursal —* nombre-sucursal 
ciudad-sucursal activo 

Como Esquema-sucursal D Esquema-info-préstamo = 
{nombre-sucursal}, se concluye que la descomposición 
inicial es una descomposición de reunión sin pérdida. 

A continuación se descompone Esquema-info-prés¬ 
tamo en 

Esquema-préstamo = ( número-préstamo, 
nombre-sucursal, importe) 
Esquema-prestatario = ( nombre-cliente, 
número-préstamo) 

Este paso da lugar a una descomposición de reunión sin 
pérdida ya que número-préstamo es un atributo común y 
número-préstamo —* importe nombre-sucursal. 

En el caso general de la descomposición simultánea 
de una relación en varias partes, la búsqueda de la des¬ 
composición de reunión sin pérdida resulta más com¬ 
plicada. Véanse las notas bibliográficas para encontrar 
referencias sobre este tema. 

Aunque la prueba de la descomposición binaria es, 
evidentemente, una condición suficiente para la reu¬ 
nión sin pérdida, sólo constituye una condición nece¬ 
saria si todas las restricciones son dependencias fun¬ 
cionales. Más adelante se verán otros tipos de 
restricciones (en especial, un tipo de restricción deno¬ 
minado dependencia multivalorada), que pueden ase¬ 
gurar que una descomposición es una reunión sin pér¬ 
dida aunque no haya ninguna dependencia funcional. 

7.5.2. Conservación de las dependencias 

Hay otro objetivo en el diseño de las bases de datos rela¬ 
ciónales: la conservación de las dependencias. Cuando 
se lleva a cabo una actualización de la base de datos el 
sistema debe poder comprobar que la actualización no 
crea ninguna relación ilegal, es decir, una relación que 
no satisface todas las dependencias funcionales dadas. 
Si hay que comprobar de manera eficiente las actuali¬ 
zaciones, se deben diseñar unos esquemas de bases de 
datos relaciónales que permitan la validación de las actua¬ 
lizaciones sin que haga falta calcular las reuniones. 

Para decidir si hay que calcular las reuniones para 
comprobar una actualización hace falta determinar las 
dependencias funcionales que hay que comprobar veri¬ 
ficando cada relación una a una. Sea F un conjunto de 
dependencias funcionales del esquema R y If, R 2 ,...,R n 
una descomposición de R. La restricción de F a R¡ es 
el conjunto F¡ de todas las dependencias funcionales de 
F + que sólo incluyen atributos de R¡. Dado que todas las 
dependencias funcionales de una restricción únicamente 
implican atributos de un esquema de relación, es posi¬ 
ble comprobar el cumplimiento de la condición por una 
dependencia verificando sólo una relación. 

Obsérvese que la definición de restricción utiliza 
todas las dependencias de F + , no sólo las de F. Por ejem- 
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pío, supóngase que se tiene F = {A —* B, B —> C} y que 
se tiene una descomposición en AC y AB. La restricción 
de F a AC es, entonces, A -> C, ya que A ^ C se halla 
en F + , aunque no se halle en F. 

El conjunto de restricciones F¡, F 2 ,..., F n es el con¬ 
junto de dependencias que pueden comprobarse de 
manera eficiente. Ahora cabe preguntarse si es sufi¬ 
ciente comprobar sólo las restricciones. Sea F' = F, U 
F 2 U ...U F n . F' es un conjunto de dependencias fun¬ 
cionales del esquema R , pero, en general F' * F. Sin 
embargo, aunque F' * F, puede ocurrir que F' + = F + . 
Si esto último es cierto, entonces cada dependencia de 
F está lógicamente implicada por F' y, si se comprue¬ 
ba que se satisface F', se habrá comprobado que se 
satisface F. Se dice que las descomposiciones que tie¬ 
nen propiedad F' + = F + son descomposiciones que 
conservan las dependencias. 

La Figura 7.12 muestra un algoritmo para la com¬ 
probación de la conservación de las dependencias. La 
entrada es un conjunto E = {R¡, R 2 ,..., R n } de esque¬ 
mas de relaciones descompuestas y un conjunto F de 
dependencias funcionales. Este algoritmo resulta cos¬ 
toso, ya que exige el cálculo de F + ; se describirá otro 
algoritmo que es más eficiente después de haber dado 
un ejemplo de comprobación de la conservación de las 
dependencias. 

Ahora se puede demostrar que la descomposición de 
Esquema-empréstito conserva las dependencias. En lugar 
de aplicar el algoritmo de la Figura 7.12, se considera 
una alternativa más sencilla: se considera cada miembro 
del conjunto de dependencias funcionales F que se exi¬ 
ge que se cumplan en Esquema-empréstito y se demues¬ 
tra que cada una de ellas puede comprobarse, como míni¬ 
mo, en una relación de la descomposición. 

• Se puede comprobar la dependencia funcional: 
nombre-sucursal —> ciudad-sucursal activo utili¬ 
zando Esquema-sucursal = ( nombre-sucursal , ciu¬ 
dad-sucursal, activo). 

• Se puede comprobar la dependencia funcional: 
número-préstamo —> importe nombre-sucursal uti- 


calcular F + ; 

for each esquema R, de E do 

begin 

F ¡: = la restricción de F* a R¡; 

end 

F := 0 

for each restricción F¡ do 
begin 

F' = F U F, 

end 

calcular F' + ; 

if (F' + = F + ) then return (true) 
else return (false); 

FIGURA 7.12. Comprobación de la conservación de las 
dependencias. 


fizando Esquema-préstamo = ( nombre-sucursal, 
número-préstamo, importe). 

Si puede comprobarse cada miembro de F en una de 
las relaciones de la descomposición, la descomposición 
conserva las dependencias. Sin embargo, hay casos en 
los que, aunque la descomposición conserve las depen¬ 
dencias, hay alguna dependencia de F que no puede 
comprobarse en ninguna relación de la descomposición. 
Se puede utilizar, por tanto, la prueba alternativa como 
condición suficiente que resulta sencilla de comprobar; 
si falla, no se puede concluir que la descomposición no 
conserve las dependencia; en lugar de eso, habrá que 
aplicar la prueba general. 

Ahora se dará una prueba más eficiente para la con¬ 
servación de las dependencias, que evita el cálculo de 
F + . La idea es comprobar cada dependencia funcional 
a —> de F empleando una forma modificada del cie¬ 
rre de los atributos para ver si la descomposición la 
conserva. Se aplica el siguiente procedimiento a cada 
a -* ¡3 de F. 

resultado = a 

while (cambios en resultado) do 

for each R¡ de la descomposición 
t = (resultado D R¡) + D R¡ 
resultado = resultado U t 

El cierre de los atributos está tomado con respecto a las 
dependencias funcionales de F. Si resultado contiene 
todos los atributos de /3, se conserva la dependencia fun¬ 
cional a —> ¡3. La descomposición conserva las depen¬ 
dencias si y sólo si se conservan todas las dependencias 
de F. 

Obsérvese que, en lugar de calcular previamente la 
restricción de F a R¡ y utilizarla para el cálculo del cie¬ 
rre de los atributos de resultado , se usa el cierre de los 
atributos en ( resultado D R¡) con respecto a F y luego se 
intersecta con R¡ para obtener un resultado equivalente. 
Este procedimiento tarda un tiempo polinómico, en lugar 
del tiempo exponencial necesario para calcular F + . 

7.5.3. Repetición de la información 

La descomposición de Esquema-empréstito no sufre el 
problema de repetición de la información que se estu¬ 
dió en el Apartado 7.2. En Esquema-empréstito era nece¬ 
sario repetir la ciudad y el activo de la sucursal para 
cada préstamo. La descomposición separa los datos de 
la sucursal y los del préstamo en relaciones diferentes, 
con lo que elimina esta redundancia. De manera pare¬ 
cida, se observa que, en Esquema-empréstito, si se con¬ 
cede un solo préstamo a varios clientes, hay que repe¬ 
tir el importe del préstamo una vez por cada cliente (así 
como la ciudad y activo de la sucursal). En la descom¬ 
posición, la relación del esquema Esquema-prestatario 
contiene la relación número-préstamo, nombre-cliente, 
y no la contiene ningún otro esquema. Por tanto, sólo 
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se tiene una tupia por préstamo para cada cliente en la 
relación de Esquema-prestatario. En las otras relacio¬ 
nes que implican a número-préstamo (las de los esque¬ 
mas Esquema-préstamo y Esquema-prestatario ) sola¬ 
mente hace falta que aparezca una tupia por préstamo. 


Evidentemente, la falta de redundancia de la des¬ 
composición es algo deseable. El grado hasta el que se 
puede conseguir esta falta de redundancia viene repre¬ 
sentado por varias formas normales, que se estudiarán 
en el resto del capítulo. 


7.6. FORMA NORMAL DE BOYCE-CODD 


Mediante las dependencias funcionales se pueden defi¬ 
nir varias formas normales que representan «buenos» 
diseños de bases de datos. En este apartado se tratará 
de la FNBC (forma normal de Boyce-Codd, que se defi¬ 
ne a continuación) y, más adelante, en el Apartado 7.7, 
se tratará de la 3FN (tercera forma normal). 

7.6.1. Definición 

Una de las formas normales mas deseables que se pue¬ 
den obtener es la forma normal de Boyce-Codd 
(FNBC ). Un esquema de relación R está en FNBC res¬ 
pecto a un conjunto de dependencias funcionales F si, 
para todas las dependencias funcionales de F + de la for¬ 
ma a—>[3, donde a C R y ¡3 C R, se cumple al menos 
una de las siguientes condiciones: 

• a —> ¡3 es una dependencia funcional trivial (es 
decir, f3Qa) 

• a es una superclave del esquema R. 

Un diseño de base de datos está en FNBC si cada miem¬ 
bro del conjunto de esquemas de relación que constitu¬ 
ye el diseño está en FNBC. 

A modo de ejemplo, considérense los siguientes 
esquemas de relación y sus respectivas dependencias 
funcionales: 

• Esquema-cliente = ( nombre-cliente, calle-cliente, 
ciudad-cliente) 

nombre-cliente —* calle-cliente ciudad-cliente 

• Esquema-sucursal = ( nombre-sucursal, activo, 
ciudad-sucursal) 

nombre-sucursal —* activo ciudad-sucursal 

• Esquema-info-préstamo = (nombre-sucursal, nom¬ 
bre-cliente, número-préstamo, importe) 
número-préstamo —> importe nombre-sucursal 

Puede afirmarse que Esquema-cliente está en FNBC. 
Obsérvese que una clave candidata para el esquema es 
nombre-cliente. Fas únicas dependencias funcionales 
no triviales que se cumplen en Esquema-cliente tienen 
a nombre-cliente a la izquierda de la flecha. Dado que 
nombre-cliente es una clave candidata, las dependen¬ 
cias funcionales con nombre-cliente en la parte izquier¬ 
da no violan la definición de FNBC. De manera pare¬ 


cida, se puede demostrar fácilmente que el esquema de 
relación Esquema-sucursal está en FNBC. 

El esquema Esquema-info-préstamo , sin embargo, 
no está en FNBC. En primer lugar, obsérvese que núme¬ 
ro-préstamo no es una superclave de Esquema-info- 
préstamo, ya que puede que haya un par de tupias que 
representen a un solo préstamo concedido a dos perso¬ 
nas, por ejemplo, 

(Centro, Sr. Pinilla, P-44, 1.000) 

(Centro, Sra. Pinilla, P-44, 1.000) 

Como no se ha relacionado ninguna dependencia fun¬ 
cional que descarte el caso anterior, número-préstamo 
no es una clave candidata. Sin embargo, la dependen¬ 
cia funcional número-préstamo —> importe es de tipo 
no trivial. Por lo tanto, Esquema-info-préstamo no satis¬ 
face la definición de FNBC. 

Se puede afirmar que Esquema-info-préstamo no está 
en una forma normal adecuada, ya que sufre del pro¬ 
blema de repetición de información que se describió en 
el Apartado 7.2. Se observa que, si hay varios nombres 
de clientes asociados a un préstamo, en una relación de 
Esquema-info-préstamo es obligatorio repetir el nom¬ 
bre de la sucursal y el importe una vez por cada clien¬ 
te. Se puede eliminar esta redundancia rediseñando la 
base de datos de forma que todos los esquemas estén en 
FNBC. Una manera de abordar este problema es tomar 
el diseño que no está en FNBC ya existente como pun¬ 
to de partida y descomponer los esquemas que no estén 
en FNBC. Considérese la descomposición de Esquema- 
info-préstamo en dos esquemas: 

Esquema-préstamo = (número-préstamo, 
nombre-sucursal, importe) 
Esquema-prestatario = ( nombre-cliente, 
número-préstamo) 

Esta descomposición es una descomposición de reunión 
sin pérdida. 

Para determinar si esos esquemas están en FNBC es 
necesario determinar las dependencias funcionales que 
se les aplican. En este ejemplo resulta sencillo ver que 

número-préstamo —> importe nombre-sucursal 

se aplica a Esquema-préstamo, y que sólo se aplican las 
dependencias funcionales triviales a Esquema-presta- 
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taño. Aunque número-préstamo no sea una superclave 
de Esquema-info-préstamo, es una clave candidata para 
Esquema-préstamo. Por tanto, los dos esquemas de la 
descomposición están en FNBC. 

Ahora resulta posible evitar la redundancia en el caso 
en que haya varios clientes asociados a un mismo prés¬ 
tamo. En la relación de Esquema-préstamo hay exacta¬ 
mente una tupia para cada préstamo, y una tupia para 
cada cliente de cada préstamo en la relación de Esque¬ 
ma-prestatario. Por tanto, no hay que repetir el nombre 
de la sucursal y el importe una vez por cada cliente aso¬ 
ciado a un préstamo. 

A menudo se puede simplificar la comprobación de 
una relación para ver si satisface FNBC: 

• Para comprobar si la dependencia no trivial a —> ¡3 
provoca una violación de FNBC hay que calcular 
a + (el cierre de los atributos de a) y comprobar si 
incluye todos los atributos de R; es decir, si es una 
superclave de R. 

• Para comprobar si el esquema de relación R se halla 
en FNBC basta con comprobar únicamente las 
dependencias del conjunto dado F en búsqueda de 
violaciones de FNBC, en lugar de comprobar todas 
las dependencias de F + . 

Se puede probar que si ninguna de las dependencias 
de F provoca una violación de FNBC, entonces ningu¬ 
na de las dependencias de F + la provocará tampoco. 

Por desgracia, el último procedimiento no funciona 
cuando una relación está descompuesta. Es decir, no bas¬ 
ta con utilizar F al comprobar la relación R¡ en la des¬ 
composición de R para buscar violaciones de FNBC. Por 
ejemplo, considérese el esquema de relación R 
( A,B,C,D,E ), con las dependencias funcionales F que 
contienen A ^ B y BC —* D. Supóngase que estuviera 
descompuesto en R^Afí) y R 2 (A,C,D,E). Ahora bien, 
ninguna de las dependencias de F contiene únicamente 
atributos de ( A.C.D.E ), por lo que puede inducir a creer 
que R 2 satisface FNBC. En realidad, hay una dependencia 
AC -» D de F + (que puede inferirse empleando la regla 
de la pseudotransitividad a partir de las dos dependen¬ 
cias de F) que demuestra que R 2 no está en FNBC. Por 
tanto, puede que se necesite alguna dependencia que esté 
en F + , pero que no está en F, para demostrar que la rela¬ 
ción descompuesta no está en FNBC. 

Fa prueba alternativa de FNBC resulta a veces más 
sencilla que el cálculo de todas las dependencias de F + . 
Para comprobar si la relación R¡ de una descomposición 
de R está en FNBC hay que aplicar esta prueba: 

• En cada subconjunto de atributos a de R¡ hay que 
comprobar que a + (el cierre de los atributos de a 
bajo F) no incluye ningún atributo de R¡- a o que 
incluye todos los atributos de R¡. 

Si algún conjunto de atributos a de R¡ viola la con¬ 
dición, considérese la siguiente dependencia funcional, 
que se puede demostrar que se encuentra en F + : 


a -> ( a + - a) Cl R¡. 

Fa dependencia anterior demuestra que R¡ viola FNBC 
y es un «testigo» de esa violación. El algoritmo de des¬ 
composición de la FNBC, que se verá en el Apartado 

7.6.2, hace uso de este testigo. 

7.6.2. Algoritmo de descomposición 

Ahora se puede exponer un método general para des¬ 
componer los esquemas de relación de manera que satis¬ 
fagan FNBC. Fa Figura 7.13 muestra un algoritmo para 
esta tarea. Si R no está en FNBC se puede descompo¬ 
ner en un conjunto de esquemas en FNBC, R u R 2 ,..., R„ 
utilizando este algoritmo. El algoritmo utiliza las depen¬ 
dencias («testigos») que demuestran la violación de 
FNBC para llevar a cabo la descomposición. 

Fa descomposición que genera este algoritmo no sólo 
está en FNBC, sino que también es una descomposición 
de reunión sin pérdida. Para ver el motivo de que el algo¬ 
ritmo genere sólo descomposiciones de reunión sin pér¬ 
dida hay que observar que, cuando se reemplaza el esque¬ 
ma R i por (R¡ - ¡3) y (a, ¡3), se cumple a -* ¡3 y (R¡ - ¡3) 
D (a, f3) = a. 

Se aplicará el algoritmo de descomposición FNBC 
al esquema Esquema-empréstito que se empleó en el 
Apartado 7.2 como ejemplo de mal diseño de base de 
datos: 

Esquema-empréstito = ( nombre-sucursal, 
ciudad-sucursal, activo, nombre-cliente, 
número-préstamo, importe) 

El conjunto de dependencias funcionales que se exige 
que se cumplan en Esquema-empréstito es 

nombre-sucursal —* activo ciudad-sucursal 
número-préstamo —> importe nombre-sucursal 

Una clave candidata para este esquema es {número- 
préstamo, nombre-cliente}. 

Se puede aplicar el algoritmo de la Figura 7.13 al 
ejemplo Esquema-empréstito de la manera siguiente: 


resultado := {/?}; 
hecho := falso; 
calcular P; 
while (not hecho) do 

¡f (hay un esquema R¡ de resultado que no esté en FNBC) 

then begin 

sea a ¡i una dependencia funcional no trivial 
que se cumple en R¡ tal que a -* R¡ no esté en 

P y a (~l p = 0; 

resultado := (resultado - R¡) U (R, - fí) U (a, p); 

end 

else hecho := cierto; 

FIGURA 7.13. Algoritmo de descomposición de FNBC. 
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• La dependencia funcional 

nombre-sucursal —> activo ciudad-sucursal 
se cumple en Esquema-empréstito, pero nombre- 
sucursal no es una superclave. Por tanto, Esque¬ 
ma-empréstito no está en FNBC. Se sustituye 
Esquema-empréstito por 

Esquema-sucursal - ( nombre-sucursal, 
ciudad-sucursal, activo) 

Esquema-info-préstamo = ( nombre-sucursal, 
nombre-cliente, número-préstamo, importe) 

• Las únicas dependencias funcionales no triviales 
que se cumplen en Esquema-sucursal incluyen a 
nombre-sucursal a la izquierda de la flecha. 
Como nombre-sucursal es una clave de Esque¬ 
ma-sucursal, la relación Esquema-sucursal está 
en FNBC. 

• La dependencia funcional 

número-préstamo —> importe nombre-sucursal 

se cumple en Esquema-info-préstamo, pero núme¬ 
ro-préstamo no es una clave de Esquema-info-prés¬ 
tamo. Se sustituye Esquema-info-préstamo por 
Esquema-préstamo = ( número-préstamo, 
nombre-sucursal, importe) 
Esquema-prestatario = ( nombre-cliente, 
número-préstamo) 

• Esquema-préstamo y Esquema-prestatario están 
en FNBC. 

Por tanto, la descomposición de Esquema-empréstito 
da lugar a tres esquemas de relación Esquema-sucur¬ 
sal, Esquema-préstamo y Esquema-prestatario, cada 
uno de los cuales está en FNBC. Estos esquemas de rela¬ 
ción son los del Apartado 7.5, donde se demostró que 
la descomposición resultante es, a un tiempo, una des¬ 
composición de reunión sin pérdida y una descomposi¬ 
ción que preserva las dependencias. 

El algoritmo de descomposición FNBC tarda un 
tiempo exponencial en el tamaño del esquema inicial, 
ya que el algoritmo para la comprobación de si la rela¬ 
ción de la descomposición satisface FNBC puede tar¬ 
dar un tiempo exponencial. Las notas bibliográficas pro¬ 
porcionan referencias de un algoritmo que puede 
calcular la descomposición FNBC en un tiempo poli- 
nómico. No obstante, el algoritmo puede «sobrenor¬ 
malizar», es decir, descomponer una relación de mane¬ 
ra innecesaria. 

7.6.3. Conservación de las dependencias 

No todas las descomposiciones FNBC conservan las 
dependencias. A modo de ejemplo, considérese el esque¬ 
ma de relación 

Esquema-asesor = (nombre-sucursal, nombre-cliente, 

nombre-asesor) 


que indica que el cliente tiene un «asesor personal» en 
una sucursal determinada. El conjunto F de depen¬ 
dencias funcionales que se exige que se cumpla en 
Esquema-asesor es 

nombre-asesor —> nombre-sucursal 
nombre-sucursal nombre-cliente —> nombre-asesor 

Evidentemente, Esquema-asesor no está en FNBC, ya 
que nombre-asesor no es una superclave. 

Si se aplica el algoritmo de la Figura 7.13 se obtie¬ 
ne la siguiente descomposición FNBC: 

Esquema -asesor-sucursal = ( nombre-asesor ; 
nombre-sucursal) 

Esquema -cliente-asesor = ( nombre-cliente, 
nombre-asesor) 

Los esquemas descompuestos sólo conservan nombre- 
asesor —* nombre-sucursal (y las dependencias triviales) 
pero el cierre de {nombre-asesor —> nombre-sucursal} 
no incluye nombre-cliente nombre-sucursal —* nombre- 
asesor. La violación de esta dependencia no puede detec¬ 
tarse a menos que se calcule la reunión. 

Para ver el motivo de que la descomposición de 
Esquema-asesor en los esquemas Esquema—asesor- 
sucursal y Esquema-cliente-asesor no conserva las 
dependencias se aplica el algoritmo de la Figura 7.12. 
Se descubre que las restricciones F l y F 2 de F para cada 
esquema son las siguientes: 

F x = { nombre-asesor —> nombre-sucursal } 

F 2 = 0 (en Esquema-asesor-cliente solamente se cum¬ 
plen las dependencias triviales) 

(En aras de la brevedad no se muestran las dependen¬ 
cias funcionales triviales.) Resulta evidente que la depen¬ 
dencia nombre-cliente nombre-sucursal —> nombre-ase- 
sor no está en (Fj U F 2 ) + aunque sí está en F + . Por tanto, 
(F¡ U F 2 ) + /F y la descomposición no conserva las 
dependencias. 

Este ejemplo demuestra que no todas las descom¬ 
posiciones FNBC conservan las dependencias. Lo que 
es más, resulta evidente que ninguna descomposición 
FNBC de Esquema-asesor puede conservar nombre- 
cliente nombre-sucursal —> nombre-asesor. Por tanto, 
el ejemplo demuestra que no se pueden cumplir siem¬ 
pre los tres objetivos del diseño: 

1. Reunión sin pérdida 

2. FNBC 

3. Conservación de las dependencias 

Recuérdese que la reunión sin pérdida es una condi¬ 
ción esencial para la descomposición, para evitar la pér¬ 
dida de información. Por tanto, es obligatorio abando¬ 
nar la FNBC o la conservación de la dependencia. En 
el Apartado 7.7 se presenta una forma normal alterna- 
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tiva, denominada tercera forma normal, que es una 
pequeña relajación de la FNBC; el motivo del empleo 
de la tercera forma normal es que en ella siempre hay 
una descomposición que conserva las dependencias. 

Hay situaciones en las que hay más de un modo de 
descomponer un esquema en su FNBC. Puede que 
algunas de estas descomposiciones conserven las 
dependencias, mientras que puede que otras no lo 
hagan. Por ejemplo, supóngase que se tiene un esque¬ 
ma de relación R(A, B, C ) con las dependencias fun¬ 
cionales A^ByB^C.A partir de este conjunto se 
puede obtener la dependencia adicional A —> C. Si se 
utilizara la dependencia A —> B (o, de manera equi¬ 


valente, A—>C) para descomponer R, se acabaría con 
dos relaciones, RfA, B ) y R 2 (A, C); la dependencia 
B —> C no se conservaría. 

Si en lugar de eso se empleara la dependencia 
B -» C para descomponer R, se acabaría con dos rela¬ 
ciones, R,(A, B ) y R 2 (B, C), que están en FNBC, y la 
descomposición, además, conserva las dependencias. 
Evidentemente, resulta preferible la descomposición 
en RfA, B) y R 2 (B, C ). En general, por tanto, el dise¬ 
ñador de la base de datos debería examinar las des¬ 
composiciones alternativas y escoger una descompo¬ 
sición que conserve las dependencias siempre que 
resulte posible. 


7.7. TERCERA FORMA NORMAL 


Como ya se ha visto, hay esquemas relaciónales en que 
la descomposición FNBC no puede conservar las depen¬ 
dencias. Para estos esquemas hay dos alternativas si se 
desea comprobar si una actualización viola alguna 
dependencia funcional: 

• Soportar el coste extra del cálculo de las reunio¬ 
nes para buscar violaciones. 

• Emplear una descomposición alternativa, la terce¬ 
ra forma normal (3FN), que se presenta a conti¬ 
nuación, que hace menos costoso el examen de las 
actualizaciones. A diferencia de FNBC, las des¬ 
composiciones 3FN pueden contener cierta redun¬ 
dancia en el esquema descompuesto. 

Se verá que siempre resulta posible hallar una des¬ 
composición de reunión sin pérdida que conserve las 
dependencias que esté en 3FN. La alternativa que se 
escoja es una decisión de diseño que debe adoptar el 
diseñador de la base de datos con base en los requisitos 
de la aplicación. 

7.7.1. Definición 

FNBC exige que todas las dependencias no triviales 
sean de la forma a —> [i donde a es una superclave. 3FN 
relaja ligeramente esta restricción permitiendo depen¬ 
dencias funcionales no triviales cuya parte izquierda no 
sea una superclave. 

Un esquema de relación R está en tercera forma 
normal (3FN) respecto a un conjunto F de dependen¬ 
cias funcionales si, para todas las dependencias funcio¬ 
nales de F + de la forma ¡3, donde a C R y ¡3 C R, 
se cumple al menos una de las siguientes condiciones: 


• a —* ¡3 es una dependencia funcional trivial. 

• a es una superclave de R. 

• Cada atributo A de ¡3 - a está contenido en algu¬ 
na clave candidata de R. 

Obsérvese que la tercera condición no dice que una sola 
clave candidata deba contener todos los atributos de 
a —> ¡í\ cada atributo A de a —> [i puede estar conteni¬ 
do en una clave candidata diferente. 

Las dos primeras alternativas son iguales que las dos 
alternativas de la definición de FNBC. La tercera alter¬ 
nativa de la definición de 3FN parece bastante intuiti¬ 
va, y no resulta evidente el motivo de su utilidad. Repre¬ 
senta, en cierto sentido, una relajación mínima de las 
condiciones de FNBC que ayudan a asegurar que cada 
esquema tenga una descomposición que conserve las 
dependencias en 3FN. Su finalidad se aclarará más ade¬ 
lante, cuando se estudie la descomposición en 3FN. 

Obsérvese que cualquier esquema que satisfaga 
FNBC satisface también 3FN, ya que cada una de sus 
dependencias funcionales satisfará una de las dos pri¬ 
meras alternativas. Por tanto, FNBC es una restricción 
más estricta que 3FN. 

La definición de 3FN permite ciertas dependencias 
funcionales que no se permitían en FNBC. Una depen¬ 
dencia a -* ¡3 que sólo satisfaga la tercera alternativa 
de la definición de 3FN no se permitiría en FNBC, pero 
sí se permite en 3FN 1 . 

Volvamos al ejemplo Esquema-asesor (Apartado 
7.6). Se demostró que este esquema de relación no tie¬ 
ne una descomposición FNBC de reunión sin pérdida 
que conserve las dependencias. Resulta, sin embargo, 
que este esquema está en 3FN. Para comprobarlo, obsér¬ 
vese que {nombre-cliente, nombre-sucursal} es una cla- 


1 Estas dependencias son ejemplos de dependencias transitivas 
(véase el Ejercicio 7.25). La definición original de 3FN venía en tér¬ 
minos de las dependencias transitivas. La definición que se ha em¬ 
pleado es equivalente, pero más sencilla de comprender. 
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ve candidata de Esquema-asesor, por lo que el único 
atributo no contenido en una clave candidata de Esque¬ 
ma-asesor es nombre-asesor. Las únicas dependencias 
funcionales no triviales de la forma 

a —> nombre-asesor 

incluyen {nombre-cliente, nombre-sucursal} como par¬ 
te de a. Dado que {nombre-cliente, nombre-sucursal} 
es una clave candidata, estas dependencias no violan la 
definición de 3FN. 

Como optimización, al buscar 3FN, se pueden con¬ 
siderar sólo las dependencias funcionales del conjunto 
dado F, en lugar de las de F + . Además, se pueden des¬ 
componer las dependencias de F de manera que su lado 
derecho consista sólo en atributos sencillos y utilizar el 
conjunto resultante en lugar de F. 

Dada la dependencia a—*f 3, se puede utilizar la mis¬ 
ma técnica basada en el cierre de los atributos que se 
empleó para FNBC para comprobar si a es una super- 
clave. Si a no es una superclave, hay que comprobar si 
cada atributo de ¡3 está contenido en alguna clave can¬ 
didata de R\ esta comprobación resulta bastante más 
costosa, ya que implica buscar las claves candidatas. De 
hecho, se ha demostrado que la comprobación de la 3FN 
resulta NP-duro; por tanto, resulta bastante improbable 
que haya algún polinomio con complejidad polinómi- 
ca en el tiempo para esta tarea. 

7.7.2. Algoritmo de descomposición 

La Figura 7.14 muestra un algoritmo para la búsqueda 
de descomposiciones de reunión sin pérdida que con¬ 
serven las dependencias en 3FN. El conjunto de depen¬ 
dencias Fe utilizado en el algoritmo es un recubrimiento 
canónico de F. Obsérvese que el algoritmo considera el 
conjunto de esquemas R¡, j = 1,2,..., i; inicialmente 
i = 0 , y en este caso el conjunto está vacío. 


sea F c un recubrimiento canónico de F; 
i := 0; 

for each dependencia funcional a -» ¡i de F c do 

¡f ninguno de los esquemas R¡, j = 1,2,..., / contiene a¡3 
then begin 

/:= i'+l; 

R, := ap; 

end 

if ninguno de los esquemas R¡, j = 1,2,..., / contiene una clave 
candidata de R 

then begin 

/':= i'+l; 

R, := cualquier clave candidata de R; 

end 

return (R v R 2 , ..., R,) 

FIGURA 7.14. Descomposición de reunión sin pérdida que 
conserva las dependencias en 3FN. 


Para ilustrar el algoritmo de la Figura 7.14 considé¬ 
rese la siguiente extensión de Esquema-asesor del Apar¬ 
tado 7.6: 

Esquema-info-asesor = ( nombre-sucursal, 

nombre-cliente, nombre-asesor, número-sucursal) 

La diferencia principal es que se incluye el número de 
la sucursal del asesor como parte de la información. Las 
dependencias funcionales para este esquema de rela¬ 
ción son: 

nombre-asesor —> nombre-sucursal número-sucursal 
nombre-cliente nombre-sucursal —* nombre-asesor 

El bucle for del algoritmo hace que se incluyan los 
siguientes esquemas en la descomposición: 

Esquema-asesor-sucursal = (nombre-ase sor, 
nombre-sucursal, número-sucursal) 
Esquema-asesor = (nombre-cliente, 
nombre-sucursal, nombre-asesor) 

Como Esquema-asesor contiene una clave candidata de 
Esquema-info-asesor, el proceso de descomposición ha 
terminado. 

El algoritmo asegura la conservación de las depen¬ 
dencias creando de manera explícita un esquema para 
cada dependencia del recubrimiento canónico. Asegu¬ 
ra que la descomposición sea una descomposición de 
reunión sin pérdida garantizado que, como mínimo, un 
esquema contenga una clave candidata del esquema que 
está descomponiendo. El Ejercicio 7.19 proporciona 
algunos indicios de la prueba de que esto basta para 
garantizar una reunión sin pérdida. 

Este algoritmo también se denomina algoritmo de 
síntesis de 3FN, ya que toma un conjunto de depen¬ 
dencias y añade los esquemas uno a uno, en lugar de 
descomponer el esquema inicial de manera repetida. El 
resultado no queda definido de manera única, ya que 
cada conjunto de dependencias funcionales puede tener 
más de un recubrimiento canónico y, además, en algu¬ 
nos casos el resultado del algoritmo depende del orden 
en que considere las dependencias de F c . 

Si una relación R¡ está en la descomposición gene¬ 
rada por el algoritmo de síntesis, entonces R¡ está en 
3FN. Recuérdese que, cuando se busca 3FN, basta con 
considerar las dependencias funcionales cuyo lado dere¬ 
cho sea un solo atributo. Por tanto, para ver si If está 
en 3FN, hay que convencerse de que cualquier depen¬ 
dencia funcional y —» B que se cumpla en R¡ satisface 
la definición de 3FN. Supóngase que la dependencia 
que generó R¡ en el algoritmo de síntesis es a — » j3. Aho¬ 
ra bien, B debe estar en a o en ¡3, ya que B está en R¡ y 
a—* ¡3 generó R¡. Considérense los tres casos posibles: 
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B está tanto en a como en [i. En este caso, la depen¬ 
dencia a —> ¡3 no habría estado en F c , ya que B sería 
raro en ¡3. Por tanto, este caso no puede darse. 
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• B está en ¡3 pero no en a. Considérense dos casos: 

- yes una superclave. Se satisface la segunda con¬ 
dición de 3FN. 

- y no es superclave. Entonces a debe contener 
algún atributo que no se halle en y. Ahora bien, 
como y -* B se halla en F + , debe poder obtenerse 
a partir de F c mediante el algoritmo del cierre de 
atributos de y. La obtención no podría haber 
empleado ¡3 -para hacerlo, a debe estar con¬ 
tenido en el cierre de los atributos de y, lo que 
no resulta posible, ya que se ha dado por supues¬ 
to que y no es una superclave. Ahora bien, emple¬ 
ando a—> (¡3- {5}) y y-» B, se puede obtener 

B (ya que y C a¡3 y que y no puede conte¬ 
ner a B porque y -» B es no trivial). Esto impli¬ 
caría que B es raro en el lado derecho de a —* ¡3, 
lo que no resulta posible, ya que a —> ¡3 está en 
el recubrimiento canónico F c . Por tanto, si B está 
en ¡3, entonces y debe ser una superclave, y se 
satisface la segunda condición de 3FN. 

• B está en a pero no en ¡3. 

Como a/3 es una clave candidata, se satisface 
la tercera alternativa de la definición de 3FN. 

Resulta de interés que el algoritmo que se ha des¬ 
crito para la descomposición en 3FN pueda implemen- 
tarse en tiempo polinómico, aunque la comprobación 
de una relación dada para ver si satisface 3FN sea NP- 
duro. 

7.7.3. Comparación entre FNBC y 3FN 

De las dos formas normales para los esquemas de las 
bases de datos relaciónales, 3FN y FNBC, hay ventajas 
en 3FN porque se sabe que siempre resulta posible obte¬ 
ner un diseño en 3FN sin sacrificar la reunión sin pér¬ 
dida o la conservación de las dependencias. Sin embar¬ 
go, hay inconvenientes en 3FN: si no se eliminan todas 
las dependencias transitivas de las relaciones de los 
esquemas, puede que se tengan que emplear valores 
nulos para representar algunas de las relaciones signi¬ 
ficativas posibles entre los datos, y está el problema de 
repetición de la información. 

Como ilustración del problema de los valores nulos, 
considérese de nuevo Esquema-asesor y las dependen¬ 
cias funcionales asociadas. Dado que nombre-asesor —> 
nombre-sucursal, puede que se desee representar las 
relaciones entre los valores de nombre-asesor y los valo¬ 
res de nombre-sucursal de la base de datos. No obstan¬ 
te, si se va a hacer eso, o bien debe existir el valor corres¬ 
pondiente de nombre-cliente o bien hay que utilizar un 
valor nulo para el atributo nombre-cliente. 

Como ilustración del problema de repetición de infor¬ 
mación, considérese el ejemplo de Esquema-asesor de 
la Figura 7.15. Obsérvese que la información que indi¬ 
ca que González trabaja en la sucursal Navacerrada está 
repetida. 


nombre-cliente 

nombre-asesor 

nombre-sucursal 

Santos 

González 

Navacerrada 

Gómez 

González 

Navacerrada 

López 

González 

Navacerrada 

Sotoca 

González 

Navacerrada 

Pérez 

González 

Navacerrada 

Abril 

González 

Navacerrada 


FIGURA 7.15. Ejemplo de Esquema-asesor. 


Recuérdese que los objetivos del diseño de bases de 
datos con dependencias funcionales son: 

1. FNBC 

2. Reunión sin pérdida 

3. Conservación de las dependencias 

Como no siempre resulta posible satisfacer las tres, pue¬ 
de que haya que escoger entre FNBC y la conservación 
de las dependencias con 3FN. 

Merece la pena destacar que SQL no proporciona 
una manera de especificar las dependencias funciona¬ 
les, salvo para el caso especial de la declaración de las 
superclaves mediante las restricciones primary key o 
unique. Resulta posible, aunque un poco complicado, 
escribir afirmaciones que hagan que se cumpla una 
dependencia funcional (véase el Ejercicio 7.15); por 
desgracia, la comprobación de estas afirmaciones resul¬ 
taría muy costosa en la mayor parte de los sistemas de 
bases de datos. Por tanto, aunque se tenga una des¬ 
composición que conserve las dependencias, si se uti¬ 
liza SQL estándar, no se podrá comprobar de manera 
eficiente las dependencias funcionales cuyo lado izquier¬ 
do no sea una clave. 

Aunque puede que la comprobación de las depen¬ 
dencias funcionales implique una reunión si la descom¬ 
posición no conserva las dependencias, se puede redu¬ 
cir el coste empleando las vistas materializadas, que la 
mayor parte de los sistemas de bases de datos soporta. 
Dada una descomposición FNBC que no conserve las 
dependencias, se considera cada dependencia de un recu¬ 
brimiento mínimo F c que no se conserva en la descom¬ 
posición. Para cada una de estas dependencias a -> (3, 
se define una vista materializada que calcula una reu¬ 
nión de todas las relaciones de la descomposición y pro¬ 
yecta el resultado sobre a/3. La dependencia funcional 
puede comprobarse fácilmente en la vista materializada 
mediante una restricción única (a). En el lado negativo 
hay que contar una sobrecarga espacial y temporal debi¬ 
da a la vista materializada pero, en el lado positivo, el 
programador de la aplicación no tiene que preocuparse 
por la escritura de código para hacer que los datos redun¬ 
dantes se conserven consistentes en las actualizaciones; 
es labor del sistema de bases de datos conservar la vis¬ 
ta materializada, es decir, mantenerla actualizada cuan¬ 
do se actualice la base de datos. (Más avanzado el libro, 
en el Apartado 14.5, se describe el modo en que el sis- 
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tema de bases de datos puede llevar a cabo de manera 
eficiente el mantenimiento de las vistas materializadas). 

Por tanto, en caso de que no se pueda obtener una 
descomposición FNBC que conserve las dependencias, 


suele resultar preferible optar por FNBC y utilizar 
técnicas como las vistas materializadas para reducir el 
coste de la comprobación de las dependencias funcio¬ 
nales. 


7.8. CUARTA FORMA NORMAL 


No parece que algunos esquemas de relación, aunque 
se hallen en FNBC, estén lo bastante normalizados, en 
el sentido de que siguen sufriendo el problema de la 
repetición de la información. 

Considérese nuevamente el ejemplo bancario. 
Supóngase que, en un diseño alternativo del esquema 
de la base de datos, se tiene el esquema 

Esquema-BC = ( número-préstamo, nombre-cliente, 

calle-cliente, ciudad-cliente ) 

El lector sagaz reconocerá este esquema como un esque¬ 
ma que no está en FNBC debido a la dependencia fun¬ 
cional 

nombre-cliente —* calle-cliente ciudad-cliente 

que se estableció anteriormente, y debido a que nom¬ 
bre-cliente no es una clave de Esquema-BC. Sin embar¬ 
go, supóngase que el banco está atrayendo a clientes 
ricos que tienen varios domicilios (por ejemplo, una 
residencia de invierno y otra de verano). Entonces ya 
no se deseará hacer que se cumpla la dependencia fun¬ 
cional nombre-cliente —> calle-cliente ciudad-cliente. 
Si se elimina esta dependencia funcional, se halla que 
Esquema-BC está en FNBC con respecto al conjunto 
modificado de dependencias funcionales. Sin embargo, 
aunque Esquema-BC esté ahora en FNBC, sigue exis¬ 
tiendo el problema de la repetición de la información 
que se tenía anteriormente. 

Para tratar este problema hay que definir una nueva 
forma de restricción, denominada dependencia multi- 
valorada. Como se hizo para las dependencias funcio¬ 
nales, se utilizarán las dependencias multivaloradas para 
definir una forma normal para los esquemas de relación. 
Esta forma normal, denominada cuarta forma normal 
(4FN), es más restrictiva que FNBC. Se verá que cada 
esquema 4FN se halla también en FNBC, pero que hay 
esquemas FNBC que no se hallan en 4FN. 

7.8.1. Dependencias multivaloradas 

Las dependencias funcionales impiden que ciertas tupias 
estén en una relación. Si A —» B, entonces no puede haber 
dos tupias con el mismo valor de A y diferentes valores 
de B. Las dependencias multi valoradas, por otro lado, no 
impiden la existencia de esas tupias. En lugar de eso, exi¬ 
gen que estén presentes en la relación otras tupias de una 


cierta forma. Por este motivo, las dependencias funcio¬ 
nales se denominan a veces dependencias de genera¬ 
ción de igualdad y las dependencias multivaloradas se 
conocen como dependencias de generación de tupias. 

Sea R un esquema de relación y sean a C R y (3 C R. 
La dependencia multivalorada 

a —»-> f3 

se cumple en R si, en toda relación legal r(R), para todo 
par de tupias t l y t 2 de r tales que t { [a\ = f 2 [a], existen 
unas tupias f 3 y t 4 de r tales que 

?,[«] = í 2 [a] = í 3 [a] = í 4 [a] 
í 3 [/3] = 1 1 \f>\ 

H\R — Pi = h\R — f>\ 
t 4 W\ = t 2 W] 

t 4 \R-p] = t í \R-[3] 

Esta definición es menos complicada de lo que parece. 
La Figura 7.16 muestra una representación tabular de 
q, t 2 , t 3 y f 4 . De manera intuitiva, la dependencia mul¬ 
tivalorada a —»-» ¡3 indica que la relación entre ay fies 
independiente de la relación entre a y R - ¡3. Si todas 
las relaciones del esquema R satisfacen la dependencia 
multivalorada a —*-» /í, entonces a —»-* /3 es una depen¬ 
dencia multivalorada trivial en el esquema R. Por tan¬ 
to, a -*-* f3 es trivial si f3C a o f3L) a = R. 

Para ilustrar la diferencia entre las dependencias fun¬ 
cionales y las multivaloradas, considérense de nuevo 
Esquema-BC y la relación be ( Esquema-BC ) de la Figu¬ 
ra 7.17. Hay que repetir el número de préstamo una vez 
por cada dirección que tenga un cliente, y la dirección 
en cada préstamo que tenga el cliente. Esta repetición 
es innecesaria, ya que la relación entre el cliente y su 
dirección es independiente de la relación entre ese clien¬ 
te y el préstamo. Si un cliente (por ejemplo, Gómez) 
tiene un préstamo (por ejemplo, el préstamo número P- 
23), se desea que ese préstamo esté asociado con todas 
las direcciones que tenga Gómez. Por tanto, la relación 



a 

P 

R - a - (3 

fl 

a i - a, 

a ,+1 ■■■ a, 

ay + i ■■■ a„ 

*2 

a i - a, 

b u i - b¡ 

bj + -\ ... b n 

*3 

a i - a, 

a ui ■■■ 3j 

b j+-[ • ■ • b n 

h 

a i - a, 

bu i - b¡ 

a J + i ■■■ a„ 


FIGURA 7.16. Representación tabular de a -»-» f. 
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número- 

préstamo 

nombre- 

cliente 

calle- 

cliente 

ciudad- 

cliente 

P-23 

Gómez 

Carretas 

Cerceda 

P-23 

Gómez 

Mayor 

Chinchón 

P-93 

Pérez 

Leganitos 

Aluche 


FIGURA 7.17. Relación be: ejemplo de redundancia en una 
relación FNBC. 


de la Figura 7.18 es ilegal. Para hacer que esta relación 
sea legal hay que añadir las tupias (P-23, Gómez, Mayor, 
Chinchón) y (P-27, Gómez, Carretas, Cerceda) a la rela¬ 
ción be de la Figura 7.18. 

Si se compara el ejemplo anterior con la definición 
de dependencia multivalorada, se ve que se desea que 
se cumpla la dependencia multivalorada 

nombre-cliente — 9-9 calle-cliente ciudad-cliente 

(La dependencia multivalorada nombre-cliente —*-»■ 
número-préstamo también se cumplirá. Pronto se verá 
que son equivalentes.) 

Al igual que con las dependencias funcionales, las 
dependencias multivaloradas se utilizan de dos mane¬ 
ras: 

1. Para verificar las relaciones y determinar si son 
legales bajo un conjunto dado de dependencias 
funcionales y multivaloradas. 

2. Para especificar restricciones del conjunto de re¬ 
laciones legales; de este modo, sólo habrá que 
preocuparse de las relaciones que satisfagan un 
conjunto dado de dependencias funcionales y mul¬ 
tivaloradas. 

Obsérvese que, si una relación r no satisface una depen¬ 
dencia multivalorada dada, se puede crear una relación 
r' que sí satisfaga esa dependencia multivalorada aña¬ 
diendo tupias a r. 

Supongamos que F denota un conjunto de depen¬ 
dencias funcionales y multivaloradas. El cierre F + de 
F es el conjunto de todas las dependencias funcionales 
y multivaloradas implicadas lógicamente por F. Al igual 
que se hizo para las dependencias funcionales, se pue¬ 
de calcular F + a partir de F, empleando las definiciones 
formales de las dependencias funcionales y de las depen¬ 
dencias multivaloradas. Con este razonamiento se pue¬ 
de trabajar con las dependencias multivaloradas muy 
sencillas. Afortunadamente, parece que las dependen¬ 
cias multivaloradas que se dan en la práctica son bas¬ 


número- 

nombre- 

calle- 

ciudad- 

préstamo 

cliente 

cliente 

cliente 

P-23 

Gómez 

Carretas 

Cerceda 

P-27 

Gómez 

Mayor 

Chinchón 


FIGURA 7.18. Una relación be ilegal. 


tante sencillas. Para las dependencias complejas es mejor 
razonar con conjuntos de dependencias empleando un 
sistema de reglas de inferencia. (El Apartado C.l.l del 
apéndice describe un sistema de reglas de inferencia 
para las dependencias multivaloradas.) 

A partir de la definición de dependencia multivalo¬ 
rada se puede obtener la regla siguiente: 

• Si a -> ¡3, entonces a ¡3. 

En otras palabras, cada dependencia funcional es tam¬ 
bién una dependencia multivalorada. 

7.8.2. Definición de la cuarta forma normal 

Considérese nuevamente el ejemplo del Esquema-BC 
en el que se cumple la dependencia multivalorada nom¬ 
bre-cliente — *-» calle-cliente ciudad-cliente , pero no se 
cumple ninguna dependencia funcional no trivial. Se vio 
en los primeros párrafos del Apartado 7.8 que, aunque 
Esquema-BC se halla en FNBC, el diseño no es el ide¬ 
al, ya que hay que repetir la información de la dirección 
del cliente para cada préstamo. Se verá que se puede uti¬ 
lizar la dependencia multivalorada dada para mejorar el 
diseño de la base de datos descomponiendo Esquema- 
BC en una descomposición en la cuarta forma normal. 

Un esquema de relación R está en la cuarta forma 
normal (4FN) con respecto a un conjunto F de depen¬ 
dencias funcionales y multivaloradas si, para todas las 
dependencias multivaloradas de F + de la forma a — 9-9 ¡3, 
donde a C R y ¡3 C R, se cumple, como mínimo, una de 
las condiciones siguientes 

• a —9-9 ¡3 es una dependencia multivalorada trivial. 

• a es una superclave del esquema R. 

Un diseño de base de datos está en 4FN si cada com¬ 
ponente del conjunto de esquemas de relación que cons¬ 
tituye el diseño se halla en 4FN. 

Obsérvese que la definición de 4FN sólo se diferen¬ 
cia de la definición de FNBC en el empleo de las depen¬ 
dencias multivaloradas en lugar de las dependencias 
funcionales. Todos los esquemas 4FN están en FNBC. 
Para verlo hay que darse cuenta de que, si un esquema 
R no se halla en FNBC, hay una dependencia funcional 
no trivial a—* ¡3 que se cumple en R, donde a no es una 
superclave. Como a—* ¡3 implica a — 9 -» j8, R no puede 
estar en 4FN. 

Sea R un algoritmo de descomposición y sea R u 
R 2 , ■ ■ ■ , R„ una descomposición de R. Para comprobar 
si cada esquema de relación /?, se halla en 4FN, hay que 
averiguar las dependencias multivaloradas que se cum¬ 
plen en cada R¡. Recuérdese que, para un conjunto F de 
dependencias funcionales, la restricción F¡ de F a R¡ son 
todas las dependencias funcionales de F + que sólo inclu¬ 
yen los atributos de R¡. Considérese ahora un conjunto 
F de dependencias funcionales y multivaloradas. La res¬ 
tricción de F a R¡ es el conjunto F¡ que consta de 
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1. Todas las dependencias funcionales de F + que 
sólo incluyen atributos de R¡ 

2. Todas las dependencias multivaloradas de la for¬ 
ma 

a —»-> n R¡ 

donde a C R¡ y a -»-» ¡3 está en F + . 

7.8.3. Algoritmo de descomposición 

La analogía entre 4FN y FNBC es aplicable al algorit¬ 
mo para la descomposición de los esquemas en 4FN. 
La Figura 7.19 muestra el algoritmo de descomposición 
en 4FN. Es idéntico al algoritmo de descomposición en 
FNBC de la Figura 7.13, excepto en que emplea depen¬ 
dencias multivaloradas en lugar de funcionales y en que 
utiliza la restricción de F + a R¡. 

Si se aplica el algoritmo de la Figura 7.19 a Esque- 
ma-BC se halla que nombre-cliente —»-» número-prés¬ 
tamo es una dependencia multivalorada no trivial, y que 
nombre-cliente no es una superclave de Esquema-BC. 
Siguiendo el algoritmo, se sustituye Esquema-BC por 
dos esquemas: 

Esquema-prestatario = ( nombre-cliente , 
número-préstamo) 

Esquema-cliente = ( nombre-cliente, calle-cliente, 
ciudad-cliente). 

Este par de esquemas, que se halla en 4FN, elimina el 
problema que se encontró anteriormente con la redun¬ 
dancia de Esquema-BC. 

Como ocurría cuando se trataba solamente con las 
dependencias funcionales, resultan interesantes las des¬ 
composiciones que son descomposiciones de reunión 
sin pérdida y que conservan las dependencias. El hecho 
siguiente relativo a las dependencias multivaloradas y 
las reuniones sin pérdida muestra que el algoritmo de 
la Figura 7.19 sólo genera descomposiciones de reunión 
sin pérdida: 


resultado := {R}; 
hecho := falso; 

calcular F*; Dado el esquema R„ supongamos que F¡ denota la 
restricción de F + a R, 

while (not hecho) do 

¡f (hay un esquema R, en resultado que no se halla en 4FN 
con respecto a F) 

then begin 

supongamos que a -»-» p es una dependencia 
multivalorada no trivial que se cumple en R, taI 
que a -» FU no se halla en F¡, y a n /3 = 0; 
resultado := (resultado - R f ) U ( R¡ - fi) U (a, /3); 

end 

else hecho := verdadero; 

FIGURA 7.19. Alogaritmo de descomposición en 4FN. 


• Sean R un esquema de relación y F nn conjunto de 
dependencias funcionales y multivaloradas de R. 
Supongamos que Aj y R 2 forman una descompo¬ 
sición de R. Esta descomposición será una des¬ 
composición de reunión sin pérdida de R si y sólo 
si, como mínimo, una de las siguientes dependen¬ 
cias multivaloradas se halla en F + \ 

/?, n R 2 /?, 

R\ C\ R 2 *"*■ R 2 

Recuérdese que se afirmó en el Apartado 7.5.1 que, si 
R¡ El R 2 ^ R| o /?, n R 2 —* R 2 , entonces R { y R 2 son una 
descomposición de reunión sin pérdida de R. El hecho 
anterior sobre las dependencias multivaloradas es una 
afirmación más general sobre las reuniones sin pérdi¬ 
da. Dice que, para toda descomposición de reunión sin 
pérdida de R en dos esquemas Aj y R 2 , debe cumplirse 
una de las dos dependencias R t (1 R 2 -»-» R { o R¡ fl 

R 2 -+* Ri- 

El problema de la conservación de la dependencia al 
descomponer una relación se vuelve más complejo en 
presencia de dependencias multivaloradas. El Aparta¬ 
do C.1.2 del apéndice aborda este tema. 


7.9. OTRAS FORMAS NORMALES 


La cuarta forma normal no es, de ningún modo, la forma 
normal «definitiva». Como ya se ha visto, las dependen¬ 
cias multivaloradas ayudan a comprender y a abordar 
algunas formas de repetición de la información que no 
pueden comprenderse en términos de las dependencias 
funcionales. Flay tipos de restricciones denominadas 
dependencias de reunión que generalizan las depen¬ 
dencias multivaloradas y llevan a otra forma normal deno¬ 
minada forma normal de reunión por proyección 
(FNRP) (la FNRP se denomina en algunos libros quin¬ 
ta forma normal). Hay una clase de restricciones toda¬ 
vía más generales, que lleva a una forma normal deno¬ 
minada forma normal de dominios y claves (FNDC). 


Un problema práctico del empleo de estas restric¬ 
ciones generalizadas es que no sólo es difícil razonar 
con ellas, sino que tampoco hay un conjunto de reglas 
de inferencia seguras y completas para razonar sobre 
las restricciones. Por tanto, la FNRP y la forma normal 
de dominios y claves se utilizan muy raramente. El 
Apéndice C ofrece más detalles sobre estas formas nor¬ 
males. 

Conspicua por su ausencia de este estudio de las for¬ 
mas normales es la segunda forma normal (2FN). No 
se ha estudiado porque sólo es de interés histórico. Sim¬ 
plemente se definirá, y se permitirá al lector experi¬ 
mentar con ella en el Ejercicio 7.26. 
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7.10. PROCESO GENERAL DEL DISEÑO DE BASES DE DATOS 


Hasta ahora se han examinado problemas concretos de 
las formas normales y de la normalización. En este apar¬ 
tado se estudiará el modo en que se encaja la normali¬ 
zación en proceso general de diseño de bases de datos. 

Anteriormente, en este capítulo, a partir del Aparta¬ 
do 7.4, se dio por supuesto que se da un esquema de 
relación R y que se procede a normalizarlo. Hay varios 
modos de obtener el esquema R: 

1. R puede haberse generado al convertir un dia¬ 
grama E-R en un conjunto de tablas. 

2. R puede haber sido una sola relación que contu¬ 
viera todos los atributos que resultan de interés. 
El proceso de normalización divide afien rela¬ 
ciones más pequeñas. 

3. R puede haber sido el resultado de algún diseño 
ad hoc de relaciones, que hay que comprobar para 
verificar que satisface la forma normal deseada. 

En el resto de este apartado se examinarán las implica¬ 
ciones de estos enfoques. También se examinarán algu¬ 
nos problemas prácticos del diseño de bases de datos, 
incluida la desnormalización para el rendimiento y ejem¬ 
plos de mal diseño que no detecta la normalización. 

7.10.1. El modelo E-R y la normalización 

Cuando se define con cuidado un diagrama E-R, iden¬ 
tificando correctamente todas las entidades, las tablas 
generadas a partir del diagrama E-R no necesitan más 
normalización. No obstante, puede haber dependen¬ 
cias funcionales entre los atributos de una entidad. 
Por ejemplo, supóngase que una entidad empleado 
tiene los atributos número-departamento y dirección- 
departamento , y que hay una dependencia funcional 
número-departamento —> dirección-departamento. 
Habrá que normalizar la relación generada a partir de 
empleado. 

La mayor parte de los ejemplos de estas dependen¬ 
cias surgen de un mal diseño del diagrama E-R. En el 
ejemplo anterior, si se hiciera correctamente el diagra¬ 
ma E-R, se habría creado una entidad departamento con 
el atributo dirección-departamento y una relación entre 
empleado y departamento. De manera parecida, puede 
que una relación que implique a más de dos entidades 
no se halle en una forma normal deseable. Como la 
mayor parte de las relaciones son binarias, estos casos 
resultan relativamente raros. (De hecho, algunas varian¬ 
tes de los diagramas E-R hacen realmente difícil o impo¬ 
sible especificar relaciones no binarias.) 

Las dependencias funcionales pueden ayudar a detec¬ 
tar el mal diseño E-R. Si las relaciones generadas no se 
hallan en la forma normal deseada, el problema puede 
solucionarse en el diagrama E-R. Es decir, la normali¬ 


zación puede llevarse a cabo formalmente como parte 
del modelado de los datos. De manera alternativa, la 
normalización puede dejarse a la intuición del diseña¬ 
dor durante el modelado E-R, y puede hacerse formal¬ 
mente sobre las relaciones generadas a partir del mode¬ 
lo E-R. 

7.10.2. El enfoque de la relación universal 

El segundo enfoque del diseño de bases de datos es 
comenzar con un solo esquema de relación que con¬ 
tenga todos los atributos de interés y descomponerlo. 
Uno de los objetivos al escoger una descomposición era 
que fuera una descomposición de reunión sin pérdida. 
Para considerar la carencia de pérdida se dio por supues¬ 
to que resulta válido hablar de la reunión de todas las 
relaciones de la base de datos descompuesta. 

Considérese la base de datos de la Figura 7.20, que 
muestra una descomposición de la relación info-prés- 
tamo. La figura muestra una situación en la que no se 
ha determinado todavía el importe del préstamo P-58, 
pero se desea registrar el resto de los datos del présta¬ 
mo. Si se calcula la reunión natural de estas relaciones, 
se descubre que todas las tupias que hacen referencia al 
préstamo P-58 desaparecen. En otras palabras, no hay 
relación info-préstamo correspondiente a las relaciones 
de la Figura 7.20. Las tupias que desaparecen cuando 
se calcula la reunión son tupias colgantes (véase el Apar¬ 
tado 6.2.1). Formalmente, sea r,A,), r 2 (R 2 ), ..., r n (R n ) 
un conjunto de relaciones. Una tupia t de la relación r¡ 
es una tupia colgante si t no está en la relación 

n s¡ (r l M r 2 XI • • • N r„) 

Las tupias colgantes pueden aparecer en las apli¬ 
caciones prácticas de las bases de datos. Representan 
información incompleta, como en el ejemplo, en que 
se desea almacenar datos sobre un préstamo que toda¬ 
vía se halla en proceso de negociación. La relación r { 
XI r 2 x • • • ix r„ se denomina relación universal, ya 
que implica a todos los atributos del universo defini¬ 
do por fij U fi 2 U ■ ■ • Ufi„. 


nombre-sucursal 

número-préstamo 

Collado Mediano 

P-58 


número- préstamo 

importe 




número-préstamo 

nombre-cliente 

P-58 

González 


FIGURA 7.20. Descomposición de info-préstamo. 
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La única manera de escribir una relación universal 
para el ejemplo de la Figura 7.20 es incluir los valores 
nulos en la relación universal. Se vio en el Capítulo 3 
que los valores nulos presentan varias dificultades. Debi¬ 
do a ello, puede que sea mejor ver las relaciones del 
diseño descompuesto como representación de la base 
de datos, en lugar de como la relación universal cuyo 
esquema se descompuso durante el proceso de norma¬ 
lización. (Las notas bibliográficas discuten la investi¬ 
gación sobre los valores nulos y las relaciones univer¬ 
sales.) 

Téngase en cuenta que no se puede introducir en la 
base de datos de la Figura 7.20 toda la información 
incompleta sin recurrir a los valores nulos. Por ejem¬ 
plo, no se puede introducir un número de préstamo a 
menos que se conozca, como mínimo, uno de los datos 
siguientes: 

• El nombre del cliente 

• El nombre de la sucursal 

• El importe del préstamo 

Por tanto, cada descomposición concreta define una for¬ 
ma restringida de información incompleta que es acep¬ 
table en la base de datos. 

Las formas normales que se han definido generan 
buenos diseños de bases de datos desde el punto de vis¬ 
ta de la representación de la información incompleta. 
Volviendo una vez más al ejemplo de la Figura 7.20, no 
sería deseable permitir el almacenamiento del hecho 
siguiente: «Hay un préstamo (cuyo número se desco¬ 
noce) para Santos con un importe de 100 €». Esto se 
debe a que 

número-préstamo —> nombre-cliente importe 

y, por tanto, la única manera de relacionar nombre-clien¬ 
te e importe es mediante número-préstamo. Si no se 
conoce el número del préstamo, no se puede distinguir 
este préstamo de otros préstamos con números desco¬ 
nocidos. 

En otras palabras, no se desea almacenar datos de 
los cuales se desconocen los atributos claves. Obsérve¬ 
se que las formas normales que se han definido no nos 
permiten almacenar ese tipo de información a menos 
que se utilicen los valores nulos. Por tanto, las formas 
normales permiten la representación de la información 
incompleta aceptable mediante las tupias colgantes, 
mientras que prohíben el almacenamiento de la infor¬ 
mación incompleta indeseable. 

Otra consecuencia del enfoque de la relación uni¬ 
versal del diseño de bases de datos es que los nombres 
de los atributos deben ser únicos en la relación univer¬ 
sal. No se puede utilizar nombre para hacer referencia 
tanto a nombre-cliente como a nombre-sucursal. Gene¬ 
ralmente resulta preferible utilizar nombres únicos, como 
se ha hecho aquí. No obstante, si se definen de manera 


directa los esquemas de las relaciones, en vez de en tér¬ 
minos de una relación universal, se pueden obtener rela¬ 
ciones en esquemas como los siguientes para el ejem¬ 
plo del banco: 

sucursal-préstamo ( nombre, número) 
préstamo-cliente ( número, nombre) 
importe ( número , importé) 

Obsérvese que, con las relaciones anteriores, expresio¬ 
nes como sucursal-préstamo M préstamo-cliente care¬ 
cen de sentido. En realidad, la expresión sucursal-prés¬ 
tamo xi préstamo-cliente halla los préstamos concedidos 
por las sucursales a los clientes que tienen el mismo 
nombre que la sucursal. 

En un lenguaje como SQL, sin embargo, una con¬ 
sulta que implique a sucursal-préstamo y a préstamo- 
cliente debe eliminar la ambigüedad en las referencias 
a nombre anteponiendo el nombre de la relación. En 
estos entornos los diferentes papeles de nombre (como 
nombre de la sucursal y del cliente) resultan menos pro¬ 
blemáticos y puede que sean más sencillos de utilizar. 

Es opinión de los autores de este libro que la supo¬ 
sición de un único papel -que cada nombre de atribu¬ 
to tenga un significado único en la base de datos- sue¬ 
le resultar preferible a la reutilización del mismo nombre 
en varios papeles. Cuando no se realiza la suposición, 
el diseñador de la base de datos debe ser especialmen¬ 
te cuidadoso al crear un diseño normalizado de una base 
de datos relacional. 

7.10.3. Desnormalización para el rendimiento 

A veces los diseñadores de bases de datos escogen un 
esquema que tiene información redundante; es decir, 
que no está normalizada. Utilizan la redundancia para 
mejorar el rendimiento para aplicaciones concretas. La 
penalización sufrida por no emplear un esquema nor¬ 
malizado es el trabajo extra (en términos de tiempo de 
codificación y de tiempo de ejecución) de mantener con¬ 
sistentes los datos redundantes. 

Por ejemplo, supóngase que hay que mostrar el nom¬ 
bre del titular de una cuenta junto con el número y el 
saldo de su cuenta cada vez que se tiene acceso a la 
cuenta. En el esquema normalizado esto exige una reu¬ 
nión de cuenta con impositor. 

Una alternativa para calcular la reunión sobre la mar¬ 
cha es almacenar una relación que contenga todos los 
atributos de cuenta y de impositor. Esto hace más rápi¬ 
da la visualización de la información de la cuenta. No 
obstante, la información del saldo de la cuenta se repi¬ 
te para cada persona titular de la cuenta, y la aplicación 
debe actualizar todas las copias, siempre que se actua¬ 
lice el saldo de la cuenta. El proceso de tomar un esque¬ 
ma normalizado y hacerlo no normalizado se denomi¬ 
na desnormalización, y los diseñadores lo utilizan para 
ajustar el rendimiento de los sistemas para dar soporte 
a las operaciones críticas en el tiempo. 
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Una alternativa mejor, soportada hoy en día por 
muchos sistemas de bases de datos, es emplear el esque¬ 
ma normalizado y, de manera adicional, almacenar la 
reunión o cuenta e impositor en forma de vista materia¬ 
lizada. (Recuérdese que una vista materializada es una 
vista cuyo resultado se almacena en la base de datos y se 
actualiza cuando se actualizan las relaciones utilizadas 
en la vista.) Al igual que la desnormalización, el empleo 
de las vistas materializadas supone sobrecargas de espa¬ 
cio y de tiempo; sin embargo, presenta la ventaja de que 
conservar la vista actualizada es labor del sistema de 
bases de datos, no del programador de la aplicación. 

7.10.4. Otros problemas de diseño 

Hay algunos aspectos del diseño de bases de datos que 
la normalización no aborda y, por tanto, pueden llevar 
a un mal diseño de la base de datos. A continuación se 
ofrecerán algunos ejemplos; evidentemente, conviene 
evitar esos diseños. 

Considérese la base de datos de una empresa, don¬ 
de se desea almacenar los beneficios de las compañías 
de varios años. Se puede utilizar la relación benefi- 
cios(id-empresa, año, importe ) para almacenar la infor¬ 
mación de los beneficios. La única dependencia fun¬ 
cional de esta relación es icL-empresa año —> importe, y 
esta relación se halla en FNBC. 

Un diseño alternativo es el empleo de varias rela¬ 
ciones, cada una de las cuales almacena los beneficios 
de un año diferente. Supóngase que los años de interés 
son 2000, 2001 y 2002; se tendrán, entonces, las rela¬ 
ciones de la forma beneficios-2000, beneficios-2001, 
beneficios-2002, todos los cuales se hallan en el esque¬ 


ma ( id-empresa, beneficios ). Aquí, la única dependen¬ 
cia funcional de cada relación será id-empresa —* bene¬ 
ficios, por lo que estas relaciones también se hallan en 
FNBC. 

No obstante, este diseño alternativo es, claramente, 
una mala idea: habría que crear una relación nueva cada 
año, y también habría que escribir consultas nuevas cada 
año, para tener en cuenta cada nueva relación. Las con¬ 
sultas también tendrían que ser más complicadas, ya 
que puede que tengan que hacer referencia a muchas 
relaciones. 

Otra manera más de representar los mismos datos es 
tener una sola relación empresa-año(id-empresa, bene- 
ficios-2000, beneficios-2001, beneficios-2002). En este 
caso, las únicas dependencias funcionales van de id- 
empresa hacia los demás atributos, y la relación vuel¬ 
ve a estar en FNBC. Este diseño también es una mala 
idea, ya que tiene problemas parecidos al diseño ante¬ 
rior, es decir, habría que modificar el esquema de la rela¬ 
ción y escribir consultas nuevas cada año. Las consul¬ 
tas también serían más complicadas, ya que puede que 
tengan que hacer referencia a muchos atributos. 

Las representaciones como las de la compañía empre¬ 
sa-año, con una columna para cada valor de un atribu¬ 
to, se denominan de tablas cruzadas; se emplean 
ampliamente en las hojas de cálculo, en los informes y 
en las herramientas de análisis de datos. Aunque estas 
representaciones resultan útiles para mostrárselas a los 
usuarios, por las razones que acaban de darse, no resul¬ 
tan deseables en el diseño de bases de datos. Se han pro¬ 
puesto extensiones de SQL para convertir los datos des¬ 
de una representación relacional normal en una tabla 
cruzada, para poder mostrarlos. 


7.11. RESUMEN 


• Se han mostrado algunas dificultades del diseño de 
bases de datos y el modo de diseñar de manera siste¬ 
mática esquemas de bases de datos que eviten esas 
dificultades. Entre esas dificultades están la informa¬ 
ción repetida y la imposibilidad de representar cierta 
información. 

• Se ha introducido el concepto de las dependencias fun¬ 
cionales y se ha mostrado el modo de razonar con ellas. 
Se ha puesto un énfasis especial en que las depen¬ 
dencias están implicadas lógicamente por un conjun¬ 
to de dependencias. También se ha definido el con¬ 
cepto de recubrimiento canónico, que es un conjunto 
mínimo de dependencias funcionales equivalente a un 
conjunto dado de dependencias funcionales. 

• Se ha introducido el concepto de descomposición y 
se ha mostrado que las descomposiciones deben ser 
descomposiciones de reunión sin pérdida y que, pre¬ 
feriblemente, deben conservar las dependencias. 


• Si la descomposición conserva las dependencias, dada 
una actualización de la base de datos, todas las depen¬ 
dencias funcionales pueden verificarse a partir de las 
relaciones individuales, sin calcular la reunión de las 
relaciones en la descomposición. 

• Luego se ha presentado la Forma normal de Boy- 
ce-Codd (FNBC); las relaciones en FNBC están libres 
de las dificultades ya descritas. Se ha descrito un algo¬ 
ritmo para la descomposición de las relaciones en 
FNBC. Hay relaciones para las que no hay ninguna 
descomposición FNBC que conserve las dependen¬ 
cias. 

• Se han utilizado los recubrimientos canónicos para 
descomponer una relación en 3FN, que es una peque¬ 
ña relajación de la condición FNBC. Puede que las 
relaciones en 3FN tengan alguna redundancia, pero 
siempre hay una descomposición en 3FN que con¬ 
serve las dependencias. 
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• Se ha presentado el concepto de las dependencias mul- 
tivaloradas, que especifican las restricciones que no 
pueden especificarse únicamente con las dependen¬ 
cias funcionales. Se ha definido la cuarta forma nor¬ 
mal (4FN) con las dependencias multivaloradas. El 
Apartado C.l.l del apéndice da detalles del razona¬ 
miento sobre las dependencias multivaloradas. 

• Otras formas normales, como FNRP y FNDC, eli¬ 
minan formas más sutiles de redundancia. No obs¬ 
tante, es difícil trabajar con ellas y se emplean rara 


vez. El Apéndice C ofrece detalles de estas formas 
normales. 

• Al revisar los temas de este capítulo hay que tener en 
cuenta que el motivo de que se hayan podido definir 
enfoques rigurosos del diseño de bases de datos rela¬ 
ciónales es que el modelo de datos relaciónales des¬ 
cansa sobre una base matemática sólida. Esa es una 
de las principales ventajas del modelo relacional en 
comparación con los otros modelos de datos que se 
han estudiado. 


TÉRMINOS DE REPASO 


Algoritmo de descomposición 3FN 
Algoritmo de descomposición FNBC 
Atributos raros 
Axiomas de Armstrong 

Cierre de un conjunto de dependencias funcionales 
Cierre de los conjuntos de atributos 
Conservación de las dependencias 
Cuarta forma normal 
Dependencias funcionales 
Dependencias funcionales triviales 
Dependencias multivaloradas 
Descomposición 

Descomposición de reunión sin pérdida 
Desnormalización 

Dificultades en el diseño de bases de datos relació¬ 
nales 


Dominios atómicos 
F se cumple en R 

Forma normal de Boyce-Codd (FNBC) 

Forma normal de reunión por proyección (FNRP) 

Forma normal dominios y claves 

Modelo E-R y normalización 

Primera forma normal 

R satisface F 

Recubrimiento canónico 

Relación universal 

Relaciones legales 

Restricción de F a R, 

Restricción de las dependencias multivaloradas 
Superclave 

Suposición de un papel único 
Tercera forma normal 


EJERCICIOS 


7 . 1 . Expliqúese lo que se quiere decir con repetición de la 
información e imposibilidad de representación de la in¬ 
formación. Expliqúese el motivo por el que estas pro¬ 
piedades pueden indicar un mal diseño de bases de 
datos relaciónales. 

7 . 2 . Supóngase que se descompone el esquema R = (A, B, 
C, D, E) en 


B^D 

E^A 

7 . 3 . Indíquese el motivo de que ciertas dependencias funcio¬ 
nales se denominen dependencias funcionales triviales. 

7 . 4 . Indíquense todas las dependencias funcionales que 
satisface la relación de la Figura 7.21. 


(A, B, C ) 

(A, D, E) 

Demuéstrese que esta descomposición es una des¬ 
composición de reunión sin pérdida si se cumple el si¬ 
guiente conjunto F de dependencias funcionales: 


A 

B 

C 

Si 

£>i 

c-i 

Si 

£>i 

c 2 

a 2 

b-i 

Cl 

a 2 

b, 

c 3 


FIGURA 7.21. La relación del Ejercicio 7.4. 


A -* BC 
CD -* E 
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7.5. Utilícese la definición de dependencia funcional para 
argumentar que cada uno de los axiomas de Armstrong 
(reflexividad, aumentatividad y transitividad) es correc¬ 
ta. 

7.6. Expliqúese el modo en que las dependencias funcio¬ 
nales pueden utilizarse para indicar lo siguiente: 

• Existe un conjunto de relaciones de uno a uno entre 
los conjuntos de entidades cuenta y cliente. 

• Existe un conjunto de relaciones de varios a uno entre 
los conjuntos de entidades cuenta y cliente. 

7.7. Considérese la siguiente regla propuesta para las depen¬ 
dencias funcionales: Si a -» /3 y y -> ¡3, entonces a —* y. 
Pruébese que esta regla no es segura mostrando una re¬ 
lación r que satisfaga a —* ft y y —» fi. pero no satisfaga 
a -» y. 

7.8. Utilícense los axiomas de Armstrong para probar la 
seguridad de la regla de la unión. ( Sugerencia: utilíce¬ 
se la regla de la aumentatividad para probar que, si a 
-* ¡k entonces a —* a¡3. Apliqúese nuevamente la regla 
de aumentatividad, utilizando a ^ y, y apliqúese lue¬ 
go la regla de transitividad.) 

7.9. Utilícense los axiomas de Armstrong para probar la 
corrección de la regla de la descomposición. 

7.10. Utilícense los axiomas de Armstrong para probar la 
corrección de la regla de la pseudotransitividad. 

7.11. Calcúlese el cierre del siguiente conjunto F de rela¬ 
ciones funcionales para el esquema de relación R = (A, 
B, C, D, E). 

A -* BC 
CD —» E 
B^D 
E^A 

Indíquense las claves candidatas de R. 

7.12. Utilizando las dependencias funcionales del Ejercicio 
7.11, calcúlese B + . 

7.13. Utilizando las dependencias funcionales del Ejercicio 
7.11, calcúlese el recubrimiento canónico F c . 

7.14. Considérese el algoritmo de la Figura 7.22 para calcu¬ 
lar a*. Demuéstrese que este algoritmo resulta más efi¬ 
ciente que el presentado en la Figura 7.7 (Apartado 
7.3.3) y que calcula a + de manera correcta. 

7.15. Dado el esquema de base de datos R (a, b, c) y una rela¬ 
ción r del esquema R , escríbase una consulta SQL para 
comprobar si la dependencia funcional b —» c se cum¬ 
ple en la relación r. Escríbase también una declaración 
SQL que haga que se cumpla la dependencia funcio¬ 
nal. Supóngase que no hay ningún valor nulo. 

7.16. Demuéstrese que la siguiente descomposición del 
esquema R del Ejercicio 7.2 no es una descomposición 
de reunión sin pérdida: 

(A, B, C) 

(C, D, E) 

Sugerencia: dese un ejemplo de una relación r del 
esquema R tal que 

Ha, b. c ( r ) ^ n c D E (r) * r 


7.17. Sea R¡. R 2 ,.. .,R„ una descomposición del esquema U. 

Sea u(U) una relación y sea r¡ = (u). Demuéstrese 

que 

u C M r l M r 2 IX ■ • ■ N r n 

7.18. Demuéstrese que la descomposición del Ejercicio 7.2 no 
es una descomposición que conserve las dependencias. 

7.19. Demuéstrese que es posible que una descomposición 
que conserve las dependencias en 3FN sea una des¬ 
composición de reunión sin pérdida garantizando que, 
como mínimo, un esquema contenga una clave candi- 
data para el esquema que se está descomponiendo. 
(.Sugerencia: demuéstrese que la reunión de todas las 
proyecciones en los esquemas de la descomposición 
no puede tener más tupias que la relación original.) 

7.20. Indíquense los tres objetivos de diseño de las bases de 
datos relaciónales y expliqúese el motivo de que cada 
uno de ellos sea deseable. 

7.21. Dese una descomposición de reunión sin pérdida en 
FNBC del esquema R del Ejercicio 7.2. 

7.22. Dese un ejemplo de esquema de relación R' y de un 
conjunto F' de dependencias funcionales tales que haya, 
al menos, tres descomposiciones de reunión sin pérdi¬ 
da distintas de R' en FNBC. 

7.23. Al diseñar una base de datos relacional, indíquese el 
motivo de que se pueda escoger un diseño que no sea 
FNBC. 

7.24. Dese una descomposición en 3FN de reunión sin pér¬ 
dida que conserve las dependencias del esquema R del 
Ejercicio 7.2. 

7.25. Sea un atributo primo uno que aparece como mínimo 
en una clave candidata. Sean ay ¡i conjuntos de atri¬ 
butos tales que se cumple ce —> /S, pero no se cumple 
/3 —> a. Sea A un atributo que no esté en a ni en (3 y 
para el que se cumple ¡3 -> a. Se dice que A es depen¬ 
diente de manera transitiva de a. Se puede reformular 
la definición de 3FN de la manera siguiente: un esque¬ 
ma de relación R está en la 3FN con respecto a un con¬ 
junto F de dependencias funcionales si no hay atribu¬ 
tos no primos A en R para los cuales A sea dependiente 
de manera transitiva de una clave de R. 

Demuéstrese que esta nueva definición es equiva¬ 
lente a la original. 

7.26. Una dependencia funcional [3 se denomina depen¬ 
dencia parcial si hay un subconjunto adecuado y de a 
tal que y —» /3. Se dice que ¡3 es parcialmente depen¬ 
diente de a. Un esquema de relación R está en la segun¬ 
da forma normal (2FN) si cada atributo A de R cum¬ 
ple uno de los criterios siguientes: 

• Aparece en una clave candidata. 

• No es parcialmente dependiente de una clave candi¬ 
data. 

Demuéstrese que cada esquema 3FN se halla en 2FN. 
(, Sugerencia: demuéstrese que cada dependencia par¬ 
cial es una dependencia transitiva.) 

7.27. Dados los tres objetivos del diseño de bases de datos 
relaciónales, indíquese si hay alguna razón para dise¬ 
ñar un esquema de base de datos que se halle en 2FN, 
pero que no se halle en una forma normal de orden 
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resultado ;= 2 

I* cuentadf es un array cuyo elemento iésimo contiene el número de atributos del lado izquierdo de la iésima DFque todavía no 
se sabe que estén en a* */ 

for i := 1 to IFI do 
begin 

Supongamos que /3 -» y denota la iésima DF; 
cuentadf [i] :=\f)\; 

end 

/* aparece es un array con una entrada por cada atributo. La entrada del atributo Aes una lista de enteros. Cada entero i de la lis¬ 
ta Indica que A aparece en el sado izquierdo de la /'-ésima DF */ 

for each atributo A do 
begin 

aparece [A] := NIL; 

for i := 1 to IFI do 
begin 

Supongamos que /3 -» y denota la iésima DF; 
if/AEjü then añadir i a aparece [A]; 

end 

end 

agregar (a); 
return ( resultado); 

procedure agregar (a); 
for each atributo A de a do 
begin 

¡f A resultado then 
begin 

resultado ;= resultado U {A}; 

for each elemento i de aparecelA] do 

begin 

cuentadf li] ;=cuentadf[¡] - 1; 
if cuentadf [i] ;= 0 then 
begin 

supongamos que —* y denota la /-ésima DF; 

agregar (y); 
end 

end 

end 

end 

FIGURA 7.22. Un algoritmo para calcular a + . 


superior. (Véase el Ejercicio 7.26 para obtener la defi¬ 
nición de 2FN.) 

7.28. Dese un ejemplo de esquema de relación R y un con¬ 
junto de dependencias tales que R se halle en FNBC, 
pero que no esté en 4FN. 


7.29. Expliqúese el motivo de que 4FN sea una forma nor¬ 
mal más deseable que FNBC. 

7.30. Expliqúese el modo en que pueden aparecer las tupias 
colgantes. Expliqúense los problemas que pueden pro¬ 
vocar. 


NOTAS BIBLIOGRÁFICAS 


El primer estudio de la teoría del diseño de bases de 
datos relaciónales apareció en un documento pionero 
de Codd [1970]. En ese documento Codd introducía 
también las dependencias funcionales y la primera, la 
segunda y la tercera formas normales. 

Los axiomas de Armstrong se introdujeron en Arms- 
trong [1974]. Ullman [1988] es una fuente fácilmente 
accesible de las pruebas de seguridad y de completitud 
de los axiomas de Armstrong. Ullman [1988] ofrece 
también un algoritmo para la comprobación de la des¬ 


composición de reunión sin pérdida para las descom¬ 
posiciones generales (no binarias), y muchos otros algo¬ 
ritmos, teoremas y demostraciones relativos a la teoría 
de las dependencias. Maier [1983] estudia la teoría de 
las dependencias funcionales. Graham et al. [1986] estu¬ 
dia los aspectos formales del concepto de relación legal. 

FNBC se introdujo en Codd [1972]. Las ventajas de 
FNBC se estudian en Bemstein et al. [1980a]. En Tsou 
y Fischer [1982] aparece un algoritmo polinómico en 
el tiempo para la descomposición en FNBC, y también 


188 





CAPÍTULO 7 DISEÑO DE BASES DE DATOS RELACIONALES 


puede hallarse en Ullman [1988]. Biskup et al. [1979] 
ofrecen el algoritmo que se ha utilizado aquí para bus¬ 
car una descomposición en 3FN de reunión sin pérdida 
que conserve las dependencias. Los resultados funda¬ 
mentales de la propiedad de reunión sin pérdida apare¬ 
cen en Aho et al. [1979a]. 

Las dependencias multivaloradas se estudian en Zanio- 
lo [1976]. Beeri et al. [1977] dan un conjunto de axio¬ 
mas para las dependencias multivaloradas y demuestran 
que los axiomas de los autores son seguros y completos. 


La axiomatización de este libro se basa en la suya. Los 
conceptos de 4FN, FNRP y FNDC proceden de Fagin 
[1977], Fagin [1979] y Fagin [1981], respectivamente. 

Maier [1983] presenta con detalle la teoría del dise¬ 
ño de bases de datos relaciónales. Ullman [1988] y Abi- 
teboul et al. [1995] presentan un tratamiento más teóri¬ 
co de muchas de las dependencias y formas normales 
aquí presentadas. Véanse las notas bibliográficas del 
Apéndice C para obtener más referencias de literatura 
sobre normalización. 
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BASES DE DATOS BASADAS 
EN OBJETOS Y XML 

V arias áreas de aplicación de los sistemas de bases de datos están limi¬ 
tadas por las restricciones del modelo de datos relacional. En conse¬ 
cuencia, los investigadores han desarrollado varios modelos de datos 
para abordar estos campos de aplicación. 

En esta parte se estudiará el modelo de datos orientado a objetos y el modelo 
de datos relacional orientado a objetos. Además, se estudiará XML, un lenguaje 
que puede representar datos que están menos estructurados que los de otros 
modelos de datos. 

El modelo de datos orientado a objetos, descrito en el Capítulo 8, está basado 
en el paradigma de los lenguajes de programación orientados a objetos, que en 
este momento tienen un gran uso. La herencia, la identidad de objetos, y el 
encapsulamiento (información oculta), con métodos para proporcionar una 
interfaz a los objetos, están entre los conceptos clave de la programación orien¬ 
tada a objetos que han encontrado aplicaciones en los modelos de datos. Los 
modelos de datos orientados a objetos también soportan un rico sistema de 
tipos, incluyendo tipos colección y estructurados. Mientras la herencia y, hasta 
cierto punto, los tipos complejos están también presentes en el modelo E-R, el 
encapsulamiento y la identidad de objetos distinguen el modelo de datos orien¬ 
tado a objetos frente al modelo E-R. 

Los modelos relaciónales orientados a objetos, descritos en el Capítulo 9, 
combinan rasgos de los modelos relaciónales y de los modelos orientados a 
objetos. Este modelo proporciona el sistema de tipos enriquecido de las bases 
de datos orientadas a objetos, combinado con relaciones como las básicas para 
el almacenamiento de datos. Así, se aplica la herencia a las relaciones, no sólo 
a los tipos. El modelo de datos relacional orientado a objetos proporciona una 
suave migración desde las bases de datos relaciónales que resulta atractiva para 
los vendedores de bases de datos. En consecuencia, la norma SQL: 1999 incluye 
una serie de rasgos orientados a objetos dentro de su sistema de tipos, mien¬ 
tras continúa el uso de modelos relaciónales como el modelo subyacente. 

El lenguaje XML fue designado inicialmente como una forma de añadir mayor 
cantidad de información a los documentos de texto, pero ha llegado a ser impor¬ 
tante por sus aplicaciones en intercambio de datos. XML proporciona una forma 
para representar datos que tienen estructuras anidadas, y además permite una 
gran flexibilidad estructurando datos, lo cual es importante para ciertos tipos 
de datos no tradicionales. En el Capítulo 10 se describe el lenguaje XML, y a 
continuación se presentan diferentes consultas sobre los datos representados 
en XML y la transformación de datos XML desde una forma a otra. 


CAPÍTULO 



BASES DE DATOS ORIENTADAS 
A OBJETOS 


D E igual forma que los sistemas de bases de datos fueron aplicados a rangos más 
amplios de aplicaciones, incluyendo, por ejemplo, diseño asistido por computado¬ 
ra, las limitaciones impuestas por el modelo relacional han surgido como obstácu¬ 
los. En consecuencia, los investigadores de bases de datos inventaron nuevos modelos de 
datos que resuelven las limitaciones del modelo de datos relacional. Este capítulo se con¬ 
centra en uno de ellos, el modelo orientado a objetos, que está basado en el paradigma de la 
programación orientada a objetos. El Capítulo 9 trata otro modelo de datos, el modelo de 
datos relacional orientado a objetos, que combina las características de los modelos orienta¬ 
do a objetos y relacional. 

El enfoque orientado a objetos para la programación fue introducida por primera vez con el 
lenguaje Simula 67, que se diseñó para la programación de simulaciones. Smalltalk fue uno de 
los primeros lenguajes de programación orientada a objetos para aplicaciones generales. Actual¬ 
mente, los lenguajes C++ y Java son los lenguajes de programación orientada a objetos más 
usados. 

En este capítulo se introducen los conceptos de programación orientada a objetos y a conti¬ 
nuación se considera el uso de estos conceptos en sistemas de bases de datos. 


8.1. NECESIDADES DE LOS TIPOS DE DATOS COMPLEJOS 


Las aplicaciones de bases de datos tradicionales con¬ 
sisten en tareas de procesamiento de datos, tales como 
la banca y la gestión de nóminas. Dichas aplicaciones 
presentan conceptualmente tipos de datos simples. Los 
elementos de datos básicos son registros bastante peque¬ 
ños y cuyos campos son atómicos, es decir, no contie¬ 
nen estructuras adicionales y en los que se cumple la 
primera forma normal (véase el Capítulo 7). 

En los últimos años, la demanda ha incrementado las 
formas de abordar los tipos de datos más complejos. 
Considérense, por ejemplo, un conjunto de direcciones. 
Mientras una dirección completa puede ser vista como 
un elemento de datos atómico de tipo cadena de carac¬ 
teres, esta forma de verlo escondería detalles como la 
calle, la población, la provincia, y el código postal que 
podrían ser interesantes para las consultas. Por otra par¬ 
te, si una dirección se representa dividiéndola en com¬ 
ponentes (calle, población, provincia y código postal) 
las consultas escritas serían más complicadas, pues ten¬ 
drían que mencionar cada campo. Una alternativa mejor 
es permitir tipos de datos estructurados, que admiten un 
tipo dirección con subpartes calle, población, provin¬ 
cia y código postal. 

Otro ejemplo: considérense los atributos multivalo- 
rados del modelo E-R. Tales atributos son naturales, por 
ejemplo, para la representación de números de teléfo¬ 
no, ya que las personas pueden tener más de un telé¬ 


fono. La alternativa de normalización con la creación 
de una nueva relación es costosa y artificial para este 
ejemplo. 

También como ejemplo, considérese una base de 
datos para diseño de circuitos electrónicos asistido por 
computadora. Un circuito usa muchos componentes, 
de diferentes tipos, y éstos tienen que hacer referencia 
a otros componentes a los que están conectados. Todos 
los componentes de un mismo tipo presentan las mis¬ 
mas propiedades. El modelado del circuito en la base 
de datos es más simple si se puede visualizar cada com¬ 
ponente en el diseño como un ejemplar de tipo com¬ 
ponente, y dar a cada ejemplar un identificador único. 
Los componentes del circuito pueden entonces refe¬ 
rirse a otros componentes a través de su identificador 
único. 

Supóngase ahora que unos ingenieros deseen deter¬ 
minar el consumo de energía del circuito completo. Una 
buena forma de hacer esto es ver cada componente como 
un objeto proporcionando una función usodeenergía() 
que dice cuánta energía usan las componentes. La fun¬ 
ción que computa toda la energía usada no necesita 
conocer nada sobre el interior de los componentes; sólo 
es necesario invocar a la función usodeenergía() en cada 
componente y añadirlo al resultado. 

Se examinará la cuestión planteada con más detalle 
en el resto de este capítulo. 
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8.2. EL MODELO DE DATOS ORIENTADO A OBJETOS 


En esta sección se presentan los conceptos principales 
del modelo de datos orientado a objetos: la estructura de 
éstos y las nociones de clases, herencia e identidad 
de objetos. 

8.2.1. Estructura de los objetos 

Hablando en general, los objetos se corresponden con 
las entidades del modelo E-R. El paradigma orientado 
a objetos está basado en el encapsulamiento de los datos 
y del código relacionados con cada objeto en una sola 
unidad cuyo contenido no es visible desde el exterior. 
Conceptualmente, todas las interacciones entre cada 
objeto y el resto del sistema se realizan mediante men¬ 
sajes. Por tanto, la interfaz entre cada objeto y el resto 
del sistema se define mediante un conjunto de mensa¬ 
jes permitidos. 

En general, cada objeto está asociado con 

• Un conjunto de variables que contiene los datos 
del objeto; las variables se corresponden con los 
atributos del modelo E-R. 

• Un conjunto de mensajes a los que responde; cada 
mensaje puede no tener parámetros, tener uno o 
varios. 

• Un conjunto de métodos, cada uno de los cuales 
es código que implementa un mensaje; el método 
devuelve un valor como respuesta al mensaje. 

El término mensaje en un entorno orientado a objetos 
no implica el uso de mensajes físicos en redes infor¬ 
máticas. Por el contrario hace referencia al intercambio 
de solicitudes entre los objetos independientemente de 
los detalles concretos de su implementación. Se utiliza 
a veces la expresión invocar a un método para deno¬ 
tar el hecho de enviar un mensaje a un objeto y la eje¬ 
cución del método correspondiente. 

Se puede explicar la razón del uso de este enfoque 
considerando las entidades empleado de una base de 
datos bancaria. Supóngase que el sueldo anual de cada 
empleado se calcula de manera diferente para los dis¬ 
tintos empleados. Por ejemplo, puede que los jefes 
obtengan una prima en función de los resultados del 
banco, mientras que los cajeros reciben una prima en 
función de las horas que hayan trabajado. Se puede (en 
teoría) encapsular el código para calcular su sueldo con 
cada empleado en forma de método que se ejecute en 
respuesta a un mensaje de sueldo-anual. 

Todos los objetos empleado responden al mensaje 
sueldo-anual, pero lo hacen de manera diferente. Al 
encapsular con el objeto empleado la información sobre 
el cálculo de su sueldo anual, todos los objetos em¬ 
pleado presentan la misma interfaz. Dado que la úni¬ 
ca interfaz extema presentada por cada objeto es el con¬ 


junto de mensajes a los que responde, resulta posible 
modificar las definiciones de los métodos y de las varia¬ 
bles sin afectar al resto del sistema. La posibilidad de 
modificar la definición de un objeto sin afectar al res¬ 
to del sistema se considera una de las mayores venta¬ 
jas del paradigma de la programación orientada a ob¬ 
jetos. 

Los métodos de cada objeto pueden clasificarse como 
sólo de lectura o de actualización. Los métodos sólo de 
lectura no afectan al valor de las variables de los obje¬ 
tos, mientras que los métodos de actualización sí pue¬ 
den modificarlo. Los mensajes a los que responde cada 
objeto pueden clasificarse de manera parecida como 
sólo de lectura o de actualización, según el método que 
los implemente. 

Los atributos derivados de las entidades del modelo 
E-R pueden expresarse en el modelo orientado a obje¬ 
tos como mensajes sólo de lectura. Por ejemplo, el atri¬ 
buto derivado antigüedad de una entidad empleado pue¬ 
de expresarse como el mensaje antigüedad de un objeto 
empleado. El método que implemente los mensajes, 
puede determinar la antigüedad restando la fecha-alta 
del empleado de la fecha actual. 

Hablando con rigor, en el modelo orientado a obje¬ 
tos hay que expresar cada atributo de las entidades como 
una variable y un par de mensajes del objeto corres¬ 
pondiente. La variable se utiliza para guardar el valor 
del atributo, uno de los mensajes se utiliza para leer el 
valor del atributo y el otro mensaje se utiliza para actua¬ 
lizar ese valor. Por ejemplo, el atributo dirección de la 
entidad empleado puede representarse mediante: 

• Una variable dirección. 

• Un mensaje obtener-dirección cuya respuesta sea 
la dirección. 

• Un mensaje establecer-dirección, que necesita un 
parámetro nueva-dirección, para actualizar la direc¬ 
ción. 

Sin embargo, en aras de la sencillez, muchos modelos 
orientados a objetos permiten que las variables se lean 
o se actualicen de manera directa, sin necesidad de defi¬ 
nir los mensajes para ello. 

8.2.2. Clases de objetos 

Generalmente, en una base de datos hay muchos obje¬ 
tos similares. Por similar se entiende que responden a 
los mismos mensajes, utilizan los mismos métodos y 
tienen variables del mismo nombre y del mismo tipo. 
Sería un derroche definir por separado cada uno de estos 
objetos. Por tanto, los objetos parecidos se agrupan para 
formar una clase. Cada uno de estos objetos se deno¬ 
mina ejemplar de su clase. Todos los objetos de una 
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clase comparten una definición común, pese a que se 
diferencien en los valores asignados a las variables. 

El concepto de clase del modelo orientado a objetos 
se corresponde con el concepto de entidad del modelo 
E-R. Algunos ejemplos de clases en la base de datos 
bancaria son los empleados, los clientes, las cuentas y 
los préstamos. 

La Figura 8.1 define la clase empleado en pseudo- 
código. La definición muestra las variables y los men¬ 
sajes a los que responden los objetos de la clase. En esta 
definición, cada objeto de la clase empleado contiene 
las variables nombre y dirección , ambas cadenas de 
caracteres; fecha-alta, que es una fecha, y sueldo, que 
es un entero. Cada objeto responde a los cinco mensa¬ 
jes mostrados, llamados sueldo-anual, obtener-nombre, 
obtener-dirección, establecer-dirección y antigüedad. 
El nombre de tipo que precede a cada mensaje indica el 
tipo de la respuesta al mismo. Obsérvese que el men¬ 
saje establecer-dirección utiliza el parámetro nueva- 
dirección que especifica el nuevo valor de la calle. Aun¬ 
que no lo hemos mostrado aquí, la clase empleado 
soportaría también mensajes que establecen el nombre, 
el sueldo y la fecha de alta. 

Los métodos para el manejo de mensajes suelen defi¬ 
nirse separados de la definición de clases. Los métodos 
obtener-direccióni) y establecer-dirección^) estarían 
definidos, por ejemplo, por el pseudocódigo: 

string obtener-direcciónO { 
return dirección-, 

} 

int establecer-dirección(string nueva-dirección ) { 
dirección = nueva-dirección-, 

} 

mientras que el método antigüedadQ) se definiría: 

int antigüedad(){ 

return today () - fecha-alta-, 

} 

Aquí, asumimos que la función todayQ es una función 
que devuelve la fecha actual, y el «—» opera con ellas 
devolviendo el intervalo entre las dos fechas. 

class empleado { 

/* Variables */ 
string nombre; 
string dirección; 
date fecha-alta; 
int sueldo; 

/* Mensajes */ 

int sueldo-anual (); 
string obtener-nombre (); 
string obtener-dirección (); 

int establecer-dirección (string nueva-dirección ); 
int antigüedad (); 

}; 

FIGURA 8.1. Definición de la clase empleado. 


El concepto de clases es parecido al concepto de los 
tipos abstractos de datos. Sin embargo, hay varios aspec¬ 
tos adicionales en el concepto de clase respecto al de 
tipos abstractos de datos. Para representar estas propie¬ 
dades adicionales, cada clase se trata como si fuera un 
objeto. Un objeto clase incluye 

• Una variable de tipo conjunto cuyo valor es el con¬ 
junto de todos los objetos que son ejemplares de 
la clase. 

• La implementación de un método para el mensa¬ 
je nuevo, que crea un nuevo ejemplar de la clase. 

Se retomarán estas características en el Apartado 8.5.2. 

8.2.3. Herencia 

Los esquemas de las bases de datos orientadas a obje¬ 
tos suelen necesitar gran número de clases. Frecuente¬ 
mente, sin embargo, varias de las clases son parecidas 
entre sí. Por ejemplo, supóngase que se tiene una base 
de datos orientada a objetos en la aplicación bancaria. 
Cabe esperar que la clase de los clientes del banco sea 
parecida a la clase de los empleados en que ambas defi¬ 
nan variables para nombre, dirección, etcétera. Sin 
embargo, hay algunas variables específicas de los emple¬ 
ados ( sueldo, por ejemplo) y otras específicas de los 
clientes ( interés-préstamo, por ejemplo). Sería conve¬ 
niente definir una representación de las variables comu¬ 
nes en un solo lugar. Esto sólo puede hacerse si se com¬ 
binan los empleados y los clientes en una sola clase. 

Para permitir la representación directa de los pare¬ 
cidos entre las clases hay que ubicarlas en una jerarquía 
de especializaciones (la relación «ES») como la defini¬ 
da en el Capítulo 2 para el modelo entidad-relación. Por 
ejemplo, se puede decir que empleado es una especia- 
lización de persona, dado que el conjunto de los em¬ 
pleados es un subconjunto del conjunto de personas. Es 
decir, todos los empleados son personas. De manera 
parecida, cliente es una especialización de persona. 

El concepto de jerarquía de clases es parecido al de 
especialización del modelo entidad-relación. Los em¬ 
pleados y los clientes pueden representarse mediante 
clases que son especializaciones de la clase persona. 
Las variables y los métodos específicos de los emplea¬ 
dos se asocian con la clase empleado. Las variables y 
los métodos específicos de los clientes se asocian con 
la clase cliente. Las variables y los métodos que se apli¬ 
can tanto a empleados como a clientes se asocian con 
la clase persona. 

En la Figura 8.2 se muestra un diagrama E-R con 
una jerarquía de especializaciones que representa a las 
personas implicadas en la operación del ejemplo ban- 
cario. En la Figura 8.3 se muestra la jerarquía de clases 
correspondiente. Las clases mostradas en la jerarquía 
pueden definirse en pseudocódigo como se muestra en 
la Figura 8.4. Por brevedad no se presentan todos los 
mensajes y métodos asociados con estas clases, aunque 
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FIGURA 8.2. Jerarquía de especializaciones para el ejemplo 
bancarlo. 


se deben incluir en una definición completa de la base 
de datos bancaria. 

La palabra clave isa (es) se utiliza para indicar que 
una clase es una especialización de otra. Las especiali¬ 
zaciones de las clases se denominan subclases. Por tan¬ 
to, por ejemplo, empleado es una subclase de persona 
y cajero es una subclase de empleado. Análogamente, 
empleado es una superclase de cajero y persona es una 
superclase de empleado. 

Los objetos que representan a administrativos con¬ 
tienen todas las variables de la clase administrativo ; 
además, los objetos que representan a administrativos 
contienen también todas las variables de las clases 
empleado y persona. Esto se debe a que los adminis¬ 
trativos se definen como empleados y, como los em¬ 
pleados a su vez se definen como personas, se puede 
deducir que los administrativos son también personas. 
Esta propiedad de que los objetos de una clase conten¬ 
gan las variables definidas en sus superclases se deno¬ 
mina herencia de las variables. 

Los mensajes y los métodos se heredan de modo 
idéntico a las variables. Una ventaja importante de la 


persona 



empleado cliente 



administrativo cajero secretario 

FIGURA 8.3. Jerarquía de clases correspondiente a la Figu¬ 
ra 8.2. 


class persona { 
string nombre; 
string dirección; 
string obtener-nombreO; 
string obtener-dirección!); 

int establecer-dirección(string nueva-dirección); 

}; 

class cliente isa persona { 
int interés-préstamo; 

}; 

class empleado isa persona { 
date fecha-alta; 

int sueldo; 

int sueldo-anualO; 

int antigüedad(); 

}; 

class administrativo isa empleado { 
int número-despacho; 

int número-cuenta-corriente; 

}; 

class cajero isa empleado { 
int horas-semana; 

int número-ventanilla; 

}; 

class secretario isa empleado { 
int horas-semana; 

string jefe; 

}; 

FIGURA 8.4. Definición en pseudocódlgo de una jerarquía 
de clases. 


herencia en los sistemas orientados a objetos es el con¬ 
cepto de posibilidad de sustitución: cualquier méto¬ 
do de una clase dada —por ejemplo, A (o una función 
que utilice un objeto de la clase A como argumento) — 
puede ser llamado de igual modo con cualquier obje¬ 
to perteneciente a cualquier subclase B de A. Esta 
característica lleva a la reutilización del código, dado 
que no hace falta volver a escribir los mensajes, méto¬ 
dos y funciones para los objetos de la clase B. Por 
ejemplo, si se define el mensaje obtener-nombre para 
la clase persona , se puede llamar con un objeto per¬ 
sona o con cualquier objeto perteneciente a cualquie¬ 
ra de las subclases de persona , como cliente o admi¬ 
nistrativo. 

En el Apartado 8.2.2 se observó que cada clase es un 
objeto por sí misma y que ese objeto incluye una varia¬ 
ble que contiene el conjunto de todos los ejemplares de 
la clase. Resulta sencillo determinar los objetos que se 
hallan asociados con las clases en las hojas de la jerar¬ 
quía. Por ejemplo, se asocia con la clase cliente el con¬ 
junto de los clientes del banco. Para las clases que no 
son hojas, sin embargo, el problema resulta más com¬ 
plejo. En la jerarquía de la Figura 8.3 hay dos maneras 
posibles de asociar los objetos con las clases: 

1. Se pueden asociar todos los objetos empleado, 
incluyendo aquellos que sean elementos de admi¬ 
nistrativo, de cajero o de secretario, con la clase 
empleado. 
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2. Sólo se pueden asociar con la clase empleado los 
objetos empleado que no sean elementos de admi¬ 
nistrativo ni de cajero ni de secretario. 

En los sistemas orientados a objetos generalmente 
se escoge la segunda opción. En este caso resulta posi¬ 
ble determinar el conjunto de objetos empleado toman¬ 
do la unión de los objetos asociados con todas las sub¬ 
clases de empleado. La mayor parte de los sistemas 
orientados a objetos permiten que la especialización sea 
parcial; es decir, permiten objetos que pertenezcan a una 
clase, como empleado , pero que no pertenezcan a nin¬ 
guna de las subclases de la misma. 

8.2.4. Herencia múltiple 

En la mayor parte de los casos una organización de cla¬ 
ses con estructura de árbol resulta adecuada para des¬ 
cribir las aplicaciones; en la organización con estructu¬ 
ra de árbol, cada clase puede tener a lo sumo una 
superclase. Sin embargo, hay situaciones que no pue¬ 
den representarse bien en una jerarquía de clases con 
estructura de árbol. 

La herencia múltiple permite a las clases heredar 
variables y métodos de múltiples superclases. La rela¬ 
ción entre clases y subclases se representa mediante un 
grafo acíclico dirigido (GAD) en el que las clases pue¬ 
den tener más de una superclase. 

Por ejemplo, supóngase que los empleados pueden 
ser contratados por horas (para un periodo limitado) o 
bien a tiempo completo. Se pueden crear las subclases 
por-horas y a-tiempo-completo de la clase empleado. 
La subclase por-horas tendría un atributo último-día 
que especifica cuándo concluye el periodo de empleo. 
La subclase a-tiempo-completo puede tener un método 
para el cálculo de las contribuciones al plan de pensio¬ 


nes de la compañía, que no es aplicable a los emplea¬ 
dos por horas. 

La clasificación expuesta de empleados como tem¬ 
poral y a tiempo completo es independiente de la cla¬ 
sificación basada en el trabajo que ellos realizan, es 
decir, administrativo, cajero, o secretario. Se podrían 
tener administrativos a tiempo completo, administrati¬ 
vos por horas, cajeros a tiempo completo y cajeros por 
horas. Usando la herencia múltiple, simplemente se 
crea una nueva clase, tal como cajero-por-horas, que 
es una subclase de por-horas y de cajero, y cajero-a- 
tiempo-completo, que es una subclase de a-tiempo-com- 
pleto y de cajero. La combinación que no puede ocu¬ 
rrir en la vida real no necesita ser creada; por ejemplo, 
si todos los administrativos son a tiempo completo, no 
es necesario crear una clase de administrativos por 
horas. La jerarquía de clases resultantes aparece en la 
Ligura 8.5. 

Gracias a la herencia múltiple, los atributos y los 
métodos concretos de los empleados por horas y a tiem¬ 
po completo se especifican sólo una vez y los heredan 
todas las subclases. En cambio, sin la herencia múlti¬ 
ple, se debería, por ejemplo, definir administrativo-por- 
horas como una subclase de administrativo, y cajero- 
por-horas como una subclase de cajero. Los atributos 
y métodos específicos para empleados por horas ten¬ 
drían que ser repetidos en cada una de las subclases 
expuestas. 

Otro ejemplo de herencia múltiple es considerar una 
base de datos universitaria, donde una persona puede 
ser estudiante o profesor. La base de datos universita¬ 
ria puede tener clases estudiante y profesor, que son 
subclases de persona, para modelar esta situación. Con¬ 
sideremos ahora también una categoría de estudiantes 
que trabajan como ayudantes de profesor; para mode¬ 
lar esta situación se puede crear una clase ayudante-pro- 


persona 



empleado cliente 



temporal permanente administrativo cajero secretario 



FIGURA 8.5. GAD de clases del ejemplo bancario. 
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fesor como una subclase tanto de estudiante como de 
profesor. 

Cuando se utiliza la herencia múltiple aparece una 
ambigüedad potencial si se puede heredar la misma 
variable o el mismo método de más de una supercla- 
se. Por ejemplo, la clase estudiante puede tener una 
variable dept que identifica el departamento del estu¬ 
diante y la clase profesor puede tener análogamente 
una variable dept que identifica el departamento del 
profesor. La clase ayudante-profesor hereda ambas 
definiciones de la variable dept; así el uso de la varia¬ 
ble dept en el contexto de ayudantes de profesor se 
vuelve ambigua. 

El resultado de usar dept varía dependiendo de la 
implementación particular del modelo orientado a obje¬ 
tos. Por ejemplo, la implementación puede manejar dept 
de una de estas formas: 

• Incluir las dos variables, dándoles el nombre estu- 
diante.dept y profesor.dept. 

• Escoger una de las dos según el orden en que se 
crearon las clases estudiante y profesor. 

• Hacer que el usuario escoja de manera explícita 
una de las opciones en la definición de la clase ayu¬ 
dante-profesor. 

• Tratar la situación como si fuera un error. 

Ninguna de estas soluciones se ha aceptado como ópti¬ 
ma y los diferentes sistemas implementan opciones dife¬ 
rentes. 

No todos los casos de herencia múltiple llevan a 
ambigüedad. Por ejemplo, la variable sueldo está defi¬ 
nida en la clase empleados; todas las clases adminis¬ 
trativo, cajero y secretario igual que por-horas y a-tiem- 
po-completo heredan sueldo de empleado. Dado que 
estas tres clases comparten la misma definición de suel¬ 
do, no surge ambigüedad de la herencia de sueldo por 
cajero-a-tiempo-completo, administrativo-a-tiempo- 
completo, y así sucesivamente. 

Considérese de nuevo la base de datos universitaria. 
La base de datos puede tener varias subclases de per¬ 
sona, incluyendo estudiante y profesor como se vio ante¬ 
riormente en este apartado, y además subclases como 
miembro-consejo (esto es, un miembro de un consejo 
de estudiantes y profesores que se encarga de los asun¬ 
tos de los estudiantes). Un objeto puede pertenecer a 
varias de estas categorías de manera simultánea y cada 
una de éstas se denomina papel. La noción de papel aquí 
es similar a los papeles usados para la autorización en 
SQL (véase el Capítulo 6). 

Muchos lenguajes de programación orientados a 
objetos insisten en que un objeto debe tener una clase 
más específica, es decir, si un objeto pertenece a muchas 
clases, se debe pertenecer a una clase que es (directa o 
indirectamente) subclase de todas las otras clases a las 
que el objeto pertenece. Por ejemplo, si un objeto per¬ 
tenece a las clases persona y profesor, tiene que perte¬ 


necer a alguna clase que es subclase de ambas de estas 
clases. Se tiene que usar entonces herencia múltiple para 
crear todas las subclases requeridas, tales como ayu¬ 
dante-profesor (que es una subclase de estudiante y pro¬ 
fesor), estudiante-miembro-consejo, ayudante-profesor- 
miembro-consejo, etcétera, para modelar la posibilidad 
de que un objeto tenga varios papeles de manera simul¬ 
tánea. 

Claramente, la creación de muchas subclases es bas¬ 
tante incómoda, y los sistemas que no tienen necesidad 
de objetos con una clase más específica son preferibles 
para modelar papeles. En el Capítulo 9 se discute una 
ampliación de SQL que presenta una manera alternati¬ 
va de modelar papeles. 

8.2.5. Identidad de los objetos 

Los objetos de las bases de datos orientadas a objetos 
suelen corresponder a entidades del sistema modelado 
por la base de datos. Las entidades conservan su iden¬ 
tidad aunque algunas de sus propiedades cambien con 
el tiempo. De manera parecida, los objetos conservan 
su identidad aunque los valores de las variables o las 
definiciones de los métodos cambien total o parcial¬ 
mente con el tiempo. Este concepto de identidad no se 
aplica a las tupias de las bases de datos relaciónales. En 
los sistemas relaciónales las tupias de una relación sólo 
se distinguen por los valores que contienen. 

La identidad de los objetos es un concepto de iden¬ 
tidad más potente que el que suele hallarse en los len¬ 
guajes de programación o en los modelos de datos que 
no se basan en la programación orientada a objetos. 
A continuación se ilustran varios ejemplos de identi¬ 
dad. 

• Valor. Se utiliza un valor de datos como identidad. 
Esta forma de identidad se utiliza en los sistemas 
relaciónales. Por ejemplo, el valor de la clave pri¬ 
maria de una tupia identifica a la tupia. 

• Nombre. Se utiliza como identidad un nombre pro¬ 
porcionado por el usuario. Esta forma de identi¬ 
dad suele utilizarse para los archivos en los siste¬ 
mas de archivos. Cada archivo recibe un nombre 
que lo identifica de manera unívoca, independien¬ 
temente de su contenido. 

• Incorporada. Se incluye el concepto de identidad 
en el modelo de datos o en el lenguaje de progra¬ 
mación y no hace falta que el usuario proporcio¬ 
ne ningún identificador. Esta forma de identidad 
se utiliza en los sistemas orientados a objetos. Cada 
objeto recibe del sistema de manera automática un 
identificador en el momento en que se crea. 

La identidad de los objetos es una noción concep¬ 
tual; los sistemas reales necesitan un mecanismo físico 
que identifique los objetos de manera unívoca. Para los 
seres humanos se suelen utilizar como identificadores 
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los nombres, junto con otra información como la fecha 
y el lugar de nacimiento. Los sistemas orientados a obje¬ 
tos proporcionan el concepto de identificador del obje¬ 
to para identificar a los objetos. Los identificadores de 
los objetos son únicos; es decir, cada objeto tiene un 
solo identificador y no hay dos objetos que tengan el 
mismo identificador. Los identificadores de los objetos 
no tienen por qué estar en una forma con la que los seres 
humanos se encuentren cómodos; pueden ser números 
grandes, por ejemplo. La posibilidad de guardar el iden¬ 
tificador de un objeto como un campo de otro objeto es 
más importante que tener un nombre que resulte fácil 
de recordar. 

Como ejemplo del uso de los identificadores de los 
objetos, uno de los atributos de los objetos persona pue¬ 
de ser el atributo cónyuge, que es en realidad un iden¬ 
tificador del objeto persona correspondiente al cónyu¬ 
ge de la primera persona. Por tanto, el objeto persona 
puede guardar una referencia del objeto que represen¬ 
ta al cónyuge de esa persona. 

Generalmente el identificador lo genera el sistema 
de manera automática. Por el contrario, en las bases de 
datos relaciónales, el campo cónyuge de la relación per¬ 
sona será generalmente un identificador unívoco (qui¬ 
zás un número de DNI) del cónyuge de esa persona 
generado de manera externa al sistema de bases de 
datos. Hay muchas situaciones en las que hacer que el 
sistema genere identificadores de manera automática 
resulta una ventaja, dado que libera a los seres huma¬ 
nos de llevar a cabo esa tarea. Sin embargo, esta posi¬ 
bilidad debe utilizarse con precaución. Los identifica¬ 
dores generados por el sistema suelen ser específicos 
del mismo y, si se desplazan los datos a un sistema de 
bases de datos diferente, hay que traducirlos. Además, 
los identificadores generados por el sistema pueden 
resultar redundantes si las entidades que se modelan ya 
disponen de identificadores unívocos externos al siste¬ 
ma. Por ejemplo, en España los números del DNI sue¬ 
len utilizarse como identificadores unívocos de las per¬ 
sonas. 

8.2.6. Continentes de objetos 

Se pueden utilizar las referencias entre objetos para 
modelar diferentes conceptos del mundo real. Uno de 
estos objetos es el de continentes de objetos. Para ilus¬ 


trar los continentes de objetos considérese la base de 
datos simplificada para diseño de bicicletas de la Figu¬ 
ra 8.6. Cada diseño de bicicletas contiene las ruedas, 
el cuadro, los frenos y los cambios. Las ruedas, a su 
vez, contienen la llanta, un conjunto de radios y el neu¬ 
mático. Todos los componentes del diseño pueden 
modelarse como objetos y los continentes de los com¬ 
ponentes puede modelarse como continentes de obje¬ 
tos. 

Los objetos que contienen a otros objetos se deno¬ 
minan objetos complejos o compuestos. Puede haber 
varios niveles de continentes, como se muestra en la 
Figura 8.6. Esta situación crea entre los objetos una 
jerarquía de continentes. 

La jerarquía de la Figura 8.6 muestra la relación de 
continentes entre los objetos de manera esquemática 
dando los nombres de las clases en vez de los de los 
objetos concretos. Los enlaces entre las clases deben 
interpretarse como «es parte de» en lugar de la inter¬ 
pretación «es» de los enlaces de una jerarquía de heren¬ 
cias. 

Las variables de las diferentes clases no se muestran 
en la figura. Considérese la clase bicicleta. Puede incluir 
variables como marca que contengan datos descripti¬ 
vos de los elementos de la clase bicicleta. Además, la 
clase bicicleta incluye las variables que incluyen refe¬ 
rencias o conjuntos de referencias a los objetos de las 
clases ruedas, frenos, cambio y cuadro. 

El concepto de continente es importante en los sis¬ 
temas orientados a objetos porque permite que los 
diferentes usuarios examinen los datos con diferente 
detalle. Los diseñadores de ruedas pueden concen¬ 
trarse en los elementos de la clase ruedas sin tener 
que preocuparse mucho, si no tienen que preocupar¬ 
se en absoluto, de los objetos de las clases cambio o 
frenos. Los empleados de márketing que intenten fijar 
el precio de toda la bicicleta pueden hacer referencia 
a todos los datos correspondientes a la bicicleta 
haciendo referencia al elemento adecuado de la clase 
bicicleta. La jerarquía de continentes se utiliza para 
buscar todos los objetos contenidos en los objetos bici¬ 
cleta. 

En ciertas aplicaciones un objeto puede estar inclui¬ 
do en varios objetos. En esos casos la relación de con¬ 
tinentes se representa mediante un GAD en lugar de 
mediante una jerarquía. 


FIGURA 8.6. 


bicicleta 



rueda freno cambio cuadro 



llanta radios neumático palanca zapata cable 
Jerarquía de continentes de la base de datos para el diseño de bicicletas. 
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8.3. LENGUAJES ORIENTADOS A OBJETOS 


Hasta el momento se han abordado los conceptos bási¬ 
cos de la programación orientada a objetos en un nivel 
abstracto. Para poder utilizarlos en la práctica en un sis¬ 
tema de bases de datos hay que expresarlos en algún len¬ 
guaje. Esta expresión puede realizarse de dos maneras: 

1. Los conceptos de la programación orientada a 
objetos se utilizan simplemente como herramien¬ 
tas de diseño y se codifican, por ejemplo, en una 
base de datos relacional. Se sigue este enfoque 
cuando se utilizan los diagramas entidad-relación 
para modelar los datos y luego se convierten de 
manera manual en un conjunto de relaciones. 

2. Los conceptos de la programación orientada a 
objetos se incorporan en un lenguaje que se uti¬ 
liza para trabajar con la base de datos. Con este 
enfoque hay varios lenguajes posibles en los que 
se pueden integrar los conceptos: 

• Una opción es extender un lenguaje para el 
tratamiento de datos como SQL añadiendo 


tipos complejos y la programación orienta¬ 
da a objetos. Los sistemas que proporcionan 
extensiones orientadas a objetos a los siste¬ 
mas relaciónales se denominan sistemas rela¬ 
ciónales orientados a objetos. Los sistemas 
relaciónales orientados a objetos, y en con¬ 
creto las extensiones de SQL orientadas a 
objetos, se describen en el Capítulo 9. 

• Otra opción es tomar un lenguaje de pro¬ 
gramación orientado a objetos ya existente 
y extenderlo para que trabaje con las bases 
de datos. Estos lenguajes se denominan len¬ 
guajes de programación persistente. 

Hay diferentes situaciones en las que resulta más ade¬ 
cuado uno u otro de los enfoques. El segundo enfo¬ 
que se estudia en los apartados siguientes de este 
capítulo. La relación entre ambos se discute en el 
Capítulo 9, después de describir los sistemas rela¬ 
ciónales orientados a objetos. 


8.4. LENGUAJES DE PROGRAMACIÓN PERSISTENTE 


Los lenguajes de las bases de datos se diferencian de los 
lenguajes de programación tradicionales en que traba¬ 
jan directamente con datos que son persistentes, es decir, 
los datos siguen existiendo una vez que el programa que 
los creó ha concluido. Las relaciones de las bases de 
datos y las tupias de las relaciones son ejemplos de datos 
persistentes. Por el contrario, los únicos datos persis¬ 
tentes con los que los lenguajes de programación tradi¬ 
cionales trabajan directamente son los archivos. 

El acceso a las bases de datos es sólo un componen¬ 
te de las aplicaciones del mundo real. Mientras que los 
lenguajes para el tratamiento de datos como SQL son 
bastante efectivos en el acceso a los datos, se necesita 
un lenguaje de programación para implementar otros 
componentes de las aplicaciones como las interfaces de 
usuario o la comunicación con otras computadoras. La 
manera tradicional de realizar las interfaces de las bases 
de datos con los lenguajes de programación es incor¬ 
porar SQL dentro del lenguaje de programación. 

Los lenguajes de programación persistente son 
lenguajes de programación extendidos con constructo¬ 
ras para el tratamiento de datos persistentes. Los len¬ 
guajes de programación persistente pueden distinguir¬ 
se de los lenguajes con SQL incorporado de al menos 
dos maneras: 

1. En los lenguajes incorporados el sistema de tipos 
del lenguaje anfitrión suele ser diferente del sis¬ 
tema de tipos del lenguaje para el tratamiento de 


los datos. Los programadores son responsables 
de las conversiones de tipos entre el lenguaje anfi¬ 
trión y SQL. Exigir que los programadores eje¬ 
cuten esta tarea presenta varios inconvenientes: 

• El código para la conversión entre objetos y 
tupias opera fuera del sistema de tipos orien¬ 
tado a objetos y, por tanto, tiene más posi¬ 
bilidades de presentar errores no detectados. 

• La conversión en la base de datos entre el 
formato orientado a objetos y el formato 
relacional de las tupias necesita gran canti¬ 
dad de código. El código para la conversión 
de formatos, junto con el código para car¬ 
gar y descargar los datos de la base de datos, 
puede suponer un porcentaje significativo 
del código total necesario para la aplicación. 

Por el contrario, en los lenguajes de progra¬ 
mación persistente, el lenguaje de consulta se halla 
totalmente integrado con el lenguaje anfitrión y 
ambos comparten el mismo sistema de tipos. Los 
objetos se pueden crear y guardar en la base de 
datos sin ningún tipo explícito ni cambios de for¬ 
mato; los cambios de formato necesarios se rea¬ 
lizan de manera transparente. 
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2. Los programadores que utilizan lenguajes de con¬ 
sulta incorporados son responsables de la escri¬ 
tura de código explícito para la búsqueda de los 
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datos de la base de datos en la memoria. Si se rea¬ 
lizan actualizaciones, los programadores deben 
escribir código de manera explícita para volver a 
guardar los datos actualizados en la base de datos. 

Por el contrario, en los lenguajes de progra¬ 
mación persistentes los programadores pueden tra¬ 
bajar con datos persistentes sin tener que escribir 
de manera explícita código para buscarlos en la 
memoria o para volver a guardarlos en el disco. 

Se han propuesto versiones persistentes de los len¬ 
guajes de programación como Pascal. En los últimos años 
han recibido mucha atención las versiones persistentes 
de los lenguajes orientados a objetos como C++, Java y 
Smalltalk. Permiten a los programadores trabajar direc¬ 
tamente con los datos desde el lenguaje de programación, 
sin tener que pasar por un lenguaje para el tratamiento 
de los datos como SQL. Por tanto, proporcionan una 
mayor integración de los lenguajes de programación con 
las bases de datos que, por ejemplo, SQL incorporado. 

Sin embargo, los lenguajes de programación persis¬ 
tentes presentan ciertos inconvenientes que hay que 
tener presentes al decidir si conviene utilizarlos. Dado 
que los lenguajes de programación suelen ser potentes, 
resulta relativamente sencillo cometer errores de pro¬ 
gramación que dañen las bases de datos. La compleji¬ 
dad de los lenguajes hace que la optimización automá¬ 
tica de alto nivel, como la reducción de E/S de disco, 
resulte más difícil. En muchas aplicaciones la posibili¬ 
dad de las consultas declarativas resulta de gran impor¬ 
tancia, pero los lenguajes de programación persistentes 
no permiten actualmente las consultas declarativas sin 
que aparezcan problemas de algún tipo. 

A continuación se describen varios aspectos que cual¬ 
quier lenguaje de programación persistente debe abor¬ 
dar y, en apartados posteriores, se describen extensio¬ 
nes de C++ que lo hacen un lenguaje de programación 
persistente. 

8.4.1. Persistencia de los objetos 

Los lenguajes de programación orientados a objetos ya 
poseen un concepto de los mismos, un sistema de tipos 
para definir sus tipos y constructoras para crearlos. Sin 
embargo, estos objetos son transitorios, desaparecen en 
cuanto se termina el programa, igual que ocurre con las 
variables de los programas en Pascal o en C. Si se desea 
transformar uno de estos lenguajes en un lenguaje para 
la programación de bases de datos, el primer paso con¬ 
siste en proporcionar una manera de hacer persistentes 
a los objetos. Se han propuesto varios enfoques. 

• Persistencia por clases. El enfoque más sencillo, 
pero el menos conveniente, consiste en declarar 
que una clase es persistente. Todos los objetos de 
la clase son, por tanto, persistentes de manera pre¬ 
determinada. Todos los objetos de las clases no 
persistentes son transitorios. 


Este enfoque no es flexible, dado que suele 
resultar útil disponer en una misma clase tanto de 
objetos transitorios como de objetos persistentes. 
En muchos sistemas de bases de datos orientados 
a objetos la declaración de que una clase es per¬ 
sistente se interpreta como si se afirmara que los 
objetos de la clase pueden hacerse persistentes en 
vez de que todos los objetos de la clase son per¬ 
sistentes. Estas clases se podrían haber denomi¬ 
nado con más propiedad clases «que pueden ser 
persistentes». 

• Persistencia por creación. En este enfoque se 
introduce una sintaxis nueva para crear los obje¬ 
tos persistentes mediante la extensión de la sin¬ 
taxis para la creación de los objetos transitorios. 
Por tanto, los objetos son persistentes o transito¬ 
rios en función de la manera de crearlos. Este 
enfoque se sigue en varios sistemas de bases de 
datos orientados a objetos. 

• Persistencia por marcas. Una variante del enfo¬ 
que anterior es marcar los objetos como persisten¬ 
tes después de haberlos creado. Todos los objetos 
se crean como transitorios, pero, si un objeto tiene 
que persistir más allá de la ejecución del programa, 
hay que marcarlo de manera explícita antes de que 
éste concluya. A diferencia del enfoque anterior, la 
decisión sobre la persistencia o la transitoriedad se 
retrasa hasta después de la creación del objeto. 

• Persistencia por alcance. Uno o varios objetos se 
declaran objetos persistentes (objetos raíz) de 
manera explícita. Todos los demás objetos serán 
persistentes si (y sólo si) son alcanzables desde el 
objeto raíz mediante una secuencia de una o más 
referencias. 

Por tanto, todos los objetos a los que se haga 
referencia desde los objetos persistentes raíz (es 
decir, aquéllos cuyos identificadores se almacenen 
en los objetos persistentes raíz) serán persistentes. 
Pero también lo serán todos los objetos a los que 
se haga referencia desde ellos, y los objetos a los 
que estos últimos hagan referencia serán también 
persistentes, etcétera. Por tanto, los objetos per¬ 
sistentes son exactamente los alcanzables desde 
una raíz persistente. 

Este esquema tiene la ventaja de que resulta sen¬ 
cillo hacer que sean persistentes estructuras de datos 
completas con sólo declarar como persistente la 
raíz de las mismas. Sin embargo, el sistema de bases 
de datos sufre la carga de tener que seguir las cade¬ 
nas de referencias para detectar los objetos que son 
persistentes, y eso puede resultar costoso. 

8.4.2. La identidad de los objetos 
y los punteros 

En los lenguajes de programación orientados a objetos 
que no se han extendido para tratar la persistencia, al 
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crear objetos se obtienen identiñcadores de objetos tran¬ 
sitorios. Los identiñcadores de objetos transitorios sólo 
son válidos mientras se ejecuta el programa que los creó; 
después de que concluya ese programa el objeto se borra 
y el identificador pierde su sentido. Cuando se crean 
objetos persistentes se les asignan identiñcadores de ob¬ 
jetos persistentes. 

El concepto de la identidad de los objetos tiene una 
relación interesante con los punteros de los lenguajes 
de programación. Una manera sencilla de conseguir una 
identidad intrínseca es utilizar los punteros a las ubica¬ 
ciones físicas de almacenamiento. En concreto, en 
muchos lenguajes orientados a objetos como C++, los 
identiñcadores de los objetos son en realidad punteros 
internos de la memoria. 

Sin embargo, la asociación de los objetos con ubi¬ 
caciones físicas de almacenamiento puede variar con el 
tiempo. Hay varios grados de permanencia de las iden¬ 
tidades: 

• Dentro de los procedimientos. La identidad sólo 
persiste durante la ejecución de un único procedi¬ 
miento. Un ejemplo de la identidad dentro de los 
procedimientos son las variables locales del inte¬ 
rior de los procedimientos. 

• Dentro de los programas. La identidad sólo per¬ 
siste durante la ejecución de un único programa o 
una única consulta. Un ejemplo de la identidad 
dentro de los programas son las variables globa¬ 
les de los lenguajes de programación. Los punte¬ 
ros de la memoria principal o de la memoria vir¬ 
tual sólo ofrecen identidad dentro de los programas. 

• Entre programas. La identidad persiste de una 
ejecución del programa a otra. Los punteros a los 
datos del sistema de archivos del disco ofrecen 
identidad entre los programas, pero pueden cam¬ 
biar si se modifica la manera en que los datos se 
guardan en el sistema de archivos. 

• Persistente. La identidad no sólo persiste entre las 
ejecuciones del programa sino también entre las 
reorganizaciones estructurales de los datos. Es la 
forma persistente de la identidad necesaria para los 
sistemas orientados a objetos. 

En las extensiones persistentes de los lenguajes como 
C++, los identiñcadores de los objetos para los objetos 
persistentes se implementan como «punteros persisten¬ 
tes». Un puntero persistente es un tipo de puntero que, 
a diferencia de los punteros internos de la memoria, 
sigue siendo válido después del final de la ejecución del 
programa y después de algunas modalidades de reor¬ 
ganización de los datos. Los programadores pueden uti¬ 
lizar los punteros persistentes del mismo modo que uti¬ 
lizan los punteros internos de la memoria en los 
lenguajes de programación. Conceptualmente los pun¬ 


teros persistentes se pueden considerar como punteros 
a objetos de la base de datos. 

8.4.3. El almacenamiento y el acceso 
a los objetos persistentes 

¿Qué significa guardar un objeto en una base de datos? 
Evidentemente hay que guardar por separado la parte 
de datos de cada objeto. Lógicamente, el código que 
implementa los métodos de las clases debe guardarse 
en la base de datos como parte de su esquema, junto con 
las definiciones de tipos de las clases. Sin embargo, 
muchas implementaciones sólo guardan el código en 
archivos ajenos a la base de datos para evitar tener que 
integrar el software del sistema, como los compilado¬ 
res, con el sistema de bases de datos. 

Hay varias maneras de hallar los objetos de la base 
de datos. Uno de los enfoques consiste en dar nombres 
a los objetos, igual que se hace con los archivos. Este 
enfoque resulta útil con un número de objetos relativa¬ 
mente pequeño, pero no resulta práctico para millones 
de objetos. Un segundo enfoque consiste en exponer los 
identiñcadores de los objetos o los punteros persisten¬ 
tes de los objetos, que pueden guardarse de manera 
externa. A diferencia de los nombres, estos punteros no 
tienen por qué ser fáciles de recordar y pueden ser inclu¬ 
so punteros físicos dentro de la base de datos. 

Un tercer enfoque es guardar las colecciones de obje¬ 
tos y permitir que los programas iteren sobre las mis¬ 
mas para hallar los objetos deseados. Las colecciones 
de objetos pueden a su vez modelarse como objetos de 
un tipo colección. Los tipos de colecciones incluyen los 
conjuntos, los multiconjuntos (es decir, conjuntos con 
varias posibles apariciones de un mismo elemento), lis¬ 
tas, etcétera. Un caso especial de colección son las exten¬ 
siones de clases, que son la colección de todos los obje¬ 
tos pertenecientes a una clase. Si hay una extensión de 
clase para una clase dada, siempre que se cree un obje¬ 
to de la clase, el mismo se inserta en la extensión de cla¬ 
se de manera automática, y siempre que se borre un 
objeto, éste se eliminará de la extensión de clase. Las 
extensiones de clases permiten que las clases se traten 
como relaciones en las que resulta posible examinar 
todos los objetos de una clase, igual que se pueden exa¬ 
minar todas las tupias de una relación. 

La mayor parte de los sistemas de bases de datos 
orientados a objetos permiten las tres maneras de acce¬ 
so a los objetos persistentes. Todos los objetos tienen 
identiñcadores. Generalmente sólo se da nombre a las 
extensiones de las clases y a otros objetos de tipo colec¬ 
ción y, quizás, a otros objetos seleccionados, pero no se 
da nombre a la mayor parte de los objetos. Las exten¬ 
siones de las clases suelen conservarse para todas las 
clases que puedan tener objetos persistentes, pero, en 
muchas de las implementaciones, sólo contienen los 
objetos persistentes de cada clase. 


202 


CAPÍTULO 8 BASES DE DATOS ORIENTADAS A OBJETOS 


8.5. SISTEMAS C + + PERSISTENTES 


En los últimos años han aparecido varias bases de datos 
orientadas a objetos basadas en las extensiones de C++ 
persistentes (véanse las notas bibliográficas). Hay dife¬ 
rencias entre ellas en términos de la arquitectura de los 
sistemas pero tienen muchas características comunes en 
términos del lenguaje de programación. 

Varias de las características orientadas a objetos del 
lenguaje C++ permiten proporcionar un buen soporte 
para la persistencia sin modificar el propio lenguaje. Por 
ejemplo, se puede declarar una clase denominada Per- 
sistent_Object (objeto persistente) con los atributos y 
los métodos para permitir la persistencia; cualquier otra 
clase que deba ser persistente puede hacerse subclase 
de esta clase y heredará, por tanto, permitir la persis¬ 
tencia. El lenguaje C++ (igual que otros lenguajes 
modernos de programación) permite también la posibi¬ 
lidad de redefinir los nombres y los operadores de las 
funciones estándar —como +, -, el operador de desre¬ 
ferencia de punteros, etcétera— en función del tipo de 
operandos a los que se aplica. Esta posibilidad se deno¬ 
mina sobrecarga y se utiliza para redefinir los opera¬ 
dores para que se comporten de la manera deseada cuan¬ 
do operan con objetos persistentes. En el siguiente 
apartado se ofrecen ejemplos del uso de estas caracte¬ 
rísticas. 

Proporcionar apoyo a la persistencia mediante las 
bibliotecas de clases presenta la ventaja de realizar cam¬ 
bios mínimos en C++ y de resultar relativamente fácil 
de implementar. Sin embargo, presenta el inconvenien¬ 
te de que los programadores tienen que emplear mucho 
más tiempo para escribir los programas que trabajen 
con objetos persistentes y de que no resulta sencillo 
especificar las restricciones de integridad del esquema 
ni permitir las consultas declarativas. Por tanto, la mayor 
parte de las implementaciones persistentes de C++ 
extienden la sintaxis de C++, por lo menos en cierto 
grado. 

8.5.1. El lenguaje para la definición de objetos 
C++ de ODMG 

El grupo de gestión de bases de datos de objetos ( Object 
Database Management Group, ODMG) ha trabajado 
en la normalización de las extensiones de los lenguajes 
para que C++ y Smalltalk permitan la persistencia y en 
la definición de bibliotecas de clases con el mismo ob¬ 
jetivo. ODMG publicó la primera versión de su norma 
en 1993. En 1997 el grupo publicó la segunda versión, 
ODMG-2.0, que se aborda en este capítulo. 

La norma ODMG proporciona toda la funcionalidad 
mediante las bibliotecas de clases, sin ninguna exten¬ 
sión del lenguaje. Se describe la norma ODMG utili¬ 
zando ejemplos. Hay que tener un conocimiento previo 
del lenguaje de programación C++ para comprender 
completamente los ejemplos. (Véanse las notas biblio¬ 


gráficas para hallar las referencias a los textos sobre 

C++.) 

La extensión ODMG de C++ tiene dos partes: 1) el 
lenguaje de definición de objetos de C++ (C++ ODL, 
Object Definition Lcinguage) y 2) el lenguaje de mani¬ 
pulación de objetos de C++ (C++ OML, Object Mani- 
pulation Language). C++ ODL extiende la sintaxis de 
definición de tipos de C++. 

En la Figura 8.7 se muestra un ejemplo de código 
escrito en C++ ODL de ODMG. Los esquemas de las 
cuatro clases se definen en el código. Cada clase se defi¬ 
ne como subclase de d_Object y, por tanto, los objetos 
de cada clase pueden hacerse persistentes. Las clases 
Sucursal, Cuenta y Persona son subclases directas de 
d_Object. La clase Cliente es una subclase de Persona 
y es también, por tanto, una subclase de d_Object. Los 
tipos d_String, d_Date, y d_Long están entre los tipos 
estándar definidos por ODMG-2.0. El tipo d_Long indi¬ 
ca un entero de 32 bits. 

C++ no permite de manera directa el concepto de 
mensajes. Sin embargo, los métodos se pueden llamar 
directamente y pueden comportarse como las llamadas 
a los procedimientos. La declaración de la clase cuen¬ 
ta ilustra los métodos calcular_saldo() y actualizar_sal- 
do(d_Long delta), que se utilizan para leer y modificar 
el atributo saldo (no se ha presentado el código para 

class Sucursal: public d_Object{ 
public: 

cLString nombre; 
cLString dirección; 
d_Long activo; 

}; 

class Cuenta: public d_Object { 
prívate: 

dj-ong saldo; 
public: 

dj-ong número_cuenta; 
d_Set<d_Ref<Cliente» titulares; 
d^Long calcular_saldo(); 
int actualizar„saldo(d_Long delta); 

}; 

class Persona: public d_Object { 
public: 

d_String nombre; 
d„String dirección; 

}; 

class Cliente: public Persona { 
public: 

d_Date alta; 
d„Long id_cliente; 
d_Ref<Sucursal> sucursaLraíz; 
d_Set<d_Ref<Cuenta» cuentas; 

}; 

FIGURA 8.7. Ejemplo del lenguaje para la definición de obje¬ 
tos C++ de ODMG. 
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estos métodos). La declaración de la clase Cuenta mues¬ 
tra también las características de «encapsulamiento» de 
C++ (no específicas de ODMG). La palabra clave prí¬ 
vate indica que los atributos o los métodos siguientes 
sólo resultan visibles para los métodos de esa clase; 
public indica que los atributos o los métodos también 
son visibles para el resto del código. El atributo saldo 
de Cuenta se declara privado, lo que significa que nin¬ 
guna función distinta de los métodos de esa clase pue¬ 
de leerlo o escribirlo. La clase Cuenta tiene otras dos 
variables que aparecen después de la palabra clave public, 
queriendo decir que pueden ser accedidas por otros códi¬ 
gos distintos de los métodos se la clase Cuenta. 

El uso de la palabra clave public justo antes del nom¬ 
bre de una superclase indica que los atributos o los mé¬ 
todos públicos heredados de esa superclase siguen 
siendo públicos en la subclase. Estas características for¬ 
man parte de C++ estándar, y no son específicas para 
ODMG. 

El tipo d_Ref<Sucursal> utilizado en la clase Clien¬ 
te es una referencia, o puntero persistente, a un objeto 
del tipo Sucursal. El tipo d_Set<d_Ref<Cliente» uti¬ 
lizado en Cuenta es un conjunto de punteros persisten¬ 
tes a objetos del tipo Cuenta. 

Las clases d_Ref<> y d_Set<> son clases plantilla 
definidas en la norma ODMG-2.0; las normas se defi¬ 
nen de manera independiente de los tipos, y los pro¬ 
gramadores pueden crear ejemplares para los tipos nece¬ 
sarios (como d_Ref<Cuenta>) de la manera deseada. 

Las referencias entre Cliente y Cuenta representan 
una relación entre los objetos Cliente y Cuenta. La rela¬ 
ción se especifica en la siguiente restricción de integri¬ 
dad referencial: «Si un objeto Cliente tiene una refe¬ 
rencia a un objeto Cuenta desde su atributo cuentas, 
debe haber también una referencia inversa desde el 
objeto Cuenta hasta el objeto Cliente a través del atri¬ 
buto titulares». 

El programador puede especificar las restricciones de 
integridad referencial en ODMG-2.0, y el sistema auto¬ 
máticamente las mantendrá, de la forma en que se des¬ 
cribe en los siguientes párrafos. El programador especi¬ 
fica la restricción de integridad referencial entre las clases 
Cuenta y Cliente declarando los atributos titulares y cuen¬ 
tas de las dos clases, como en la Figura 8.8. La norma 
define estos atributos como ejemplares de una clase plan¬ 
tilla d_Rel_Set<T,A>. Un ejemplar de esta clase contie¬ 
ne un conjunto de referencias a objetos de tipo T. Debe 
haber un atributo en la clase T que guarda la referencia 
inversa; el nombre de este atributo está guardado en A. 
Por restricciones del lenguaje C++, no se puede usar 
directamente la cadena «titulares» o «cuentas» como un 
parámetro de la clase plantilla, así que se se usan las 
variables titulares y cuentas, que guardan las cadenas 
«titulares» y «cuentas» respectivamente. 

ODMG-2.0 conserva la integridad referencial auto¬ 
máticamente: la clase plantilla d_Rel_Ref<T,A> pro¬ 
porciona un método para la inserción de una referencia; 
este método también inserta una referencia inversa (si 


extern const char _titulares[], _cuentas[]; 
class Cliente: public Persona) 
public: 

d_ReLSet<Cuenta,„titulares> cuentas; 

}; 

class Cuenta: public d_Object{ 
public: 

d_ReLSet<Cliente, _cuentas> titulares; 

}; 

const char _titulares[] = «titulares»; 
const char _cuentas[] = «cuentas»; 

FIGURA 8.8. Restricciones de integridad referencial en ODMG 
C++ ODL. 


no está ya presente) en el atributo, cuyo nombre se guar¬ 
da en A, de la clase T. Por ejemplo, para añadir una nue¬ 
va cuenta a un cliente se inserta una referencia a la cuen¬ 
ta en el atributo cuentas de Cliente; usando el método 
para insertar de la clase d_Rel_Set<Cuenta,_t¡tulares>. 
Este método conserva la restricción de integridad refe¬ 
rencial insertando automáticamente una referencia a 
titular en la variable titulares de la cuenta. Análoga¬ 
mente, cuando el sistema lleva a cabo un borrado, el 
método correspondiente borra la referencia inversa. De 
este modo, el método garantiza que la restricción de 
integridad referencial no se viola. 

ODMG-2.0 también proporciona una clase plantilla 
d_Rel_Ref<T,A> que proporciona la integridad referen¬ 
cial a los atributos que guardan una única referencia. En 
este caso, la asignación a la variable de tipo 
d_Rel_Ref<T,A> se redefine para conservar automática¬ 
mente la referencia inversa. Supóngase que el objeto 
Sucursal tiene un atributo clientes que guardan la refe¬ 
rencia inversa al objeto Cliente. A continuación se pue¬ 
de declarar el atributo sucursal_raíz de Cliente que será 
del tipo d_Rel_Ref<Sucursal,_clientes>, donde alien¬ 
tes es una variable inicializada a la cadena «clientes». 
El atributo clientes de Sucursal sería del tipo 
d_Rel_Set<Cliente,_sucursal_raíz>, donde sucursal_raíz 
es una variable inicializada a la cadena «sucursal Jocal». 
Así, las restricciones de integridad referencial se con¬ 
servan automáticamente. 

8.5.2. El lenguaje para la manipulación 
de objetos C++ de ODMG 

En la Figura 8.9 se muestra código escrito en C++ OML 
de ODMG. Primero, el programa abre una base de datos 
y a continuación se inicia una transacción. Recuérdese 
el concepto de transacción del Apartado 4.9.5; las tran¬ 
sacciones forman una unidad de trabajo que es atómi¬ 
ca; es decir, si la transacción no se completa con éxito, 
el sistema deshace el efecto de la transacción. 

Como paso siguiente, el programa crea un objeto 
cuenta y un objeto titular usando el operador new. La 
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int crear_titular_cuenta(String nombre, String dirección) { 
cLDatabase bd_banco_obj; 
cLDatabase * bcLbanco = &bd_banco_obj; 
bd_banco->open(«BD-Banco»); 
d„Transaction Trans; 

Trans.begin (); 

d_Ref<Cuenta> cuenta = new(bd_banco,«Cuenta»)Cuenta; 
d_Ref<Cliente> clien = new(bd_banco,«Cliente») Cliente; 
clien->nombre = nombre; 
clien->direcc¡ón = dirección; 
clien->cuentas.insert_element(cuenta); 
cuenta->titulares.¡nserLelement(clien); 

.. Código para inicializar icLcliente, número de cuenta, etc. 

Trans.commit(); 

bcLbanco->close(); 

} 

FIGURA 8.9. Ejemplo del lenguaje para la manipulación de 
objetos C++ de ODMG. 

clase d_Object implementa varios métodos, incluyen¬ 
do la versión persistente del operador de asignación de 
memoria new que se utiliza en el código de ejemplo. 
Esta versión del operador new asigna el objeto a la base 
de datos especificada en vez de en la memoria. El ope¬ 
rador también toma un parámetro que especifica el nom¬ 
bre de la clase del objeto que está siendo asignado; el 
nombre de la clase se usa para seguir la trayectoria de 
qué objetos pertenecen a una determinada clase en una 
base de datos. 

El programa entonces inicializa los objetos cuenta y 
titular. Se utiliza el método insert_element de la clase 
plantilla d_Seto para insertar las referencias a los clien¬ 
tes y a las cuentas en los conjuntos adecuados después 
de crear los objetos cliente y cuenta. Si se ha declarado 
cuenta y titular de tipo d_Rel_Set, tan pronto como una 
cuenta se añada al conjunto de cuentas de un cliente, las 
referencias inversas desde el objeto cuenta (a través del 
atributo titular) se crearán automáticamente. De este 
modo, la inserción del cliente en el conjunto de titula¬ 
res de la cuenta se vuelve innecesario (aunque no inco¬ 
rrecto). De manera parecida, si se elimina una cuenta 
de un cliente, el conjunto de titulares de la cuenta se 
actualizaría automáticamente, borrando al cliente. 

Al final, el programa compromete la transacción y 
cierra la base de datos. Una transacción es una secuen¬ 
cia de pasos, delimitados por una llamada a begin (ini¬ 
ciar la transacción) y otra llamada a commit (compro¬ 
meter) o abort (abortar). Los pasos de la transacción 
forman una unidad atómica. Es decir, el sistema de ba¬ 
ses de datos garantiza que 1) si se ejecuta la operación 
commit() para una transacción, todas las actualizacio¬ 
nes hechas persistirán en la base de datos, y 2) si se eje¬ 
cuta una operación abort(), o si el programa que está 
ejecutando la transacción termina sin ejecutar commit(), 
todas las actualizaciones representadas como parte de 
la transacción serán deshechas. Si hay algún fallo antes 
de que una transacción se comprometa, el sistema des¬ 
hace todas las modificaciones de la transacción hasta el 
último estado estable. 


8.5.2.1. Extensiones de clases 

En el código de la Figura 8.9, los identificadores de los 
objetos cliente y cuenta no están explícitamente guar¬ 
dados en ningún sitio, aunque los objetos están no obs¬ 
tante en la base de datos. La cuestión natural es, una 
vez que el programa que creó estos objetos termina, 
¿cómo acceder a los objetos? Hay dos formas de hacer 
esto. 

En el primer método, la norma ODMG proporciona 
un mecanismo para especificar, como parte del esque¬ 
ma de una clase en una base de datos, que una exten¬ 
sión de clase debe mantenerse para la clase. Esta espe¬ 
cificación se puede hacer mediante herramientas 
administrativas proporcionadas por una implementa- 
ción ODMG o por una llamada a una función. Una vez 
se hace esta especificación, si un programador crea un 
objeto de la clase, digamos C, en esta base de datos, el 
sistema añade el identificador del objeto a la extensión 
de clase de la clase C. Si un programador borra un iden¬ 
tificador de objeto, el sistema borra sus identificadores 
desde la extensión de clase de C. La clase plantilla 
d_Extent se usa para acceder a los elementos en una 
extensión de clase. En el Apartado 8.5.2.2 se resume la 
forma de hacerlo. 

El segundo método es dar nombres a los objetos, 
igual que se dan nombres a los ficheros en un sistema 
de ficheros. Puesto que una base de datos puede con¬ 
tener un gran número de objetos de cada clase, dar 
nombres a todos los objetos se vuelve problemático. 
En su lugar, se puede crear un conjunto persistente 
que contenga los identificadores de todos los objetos 
en una clase, y dar un nombre al conjunto. En otras 
palabras, se crea manualmente una extensión de cla¬ 
se para la clase. Se describe con detalle en el Aparta¬ 
do 8.5.2.4. 

8.5.2.2. Iteradores 

Se puede iterar en una colección de referencias utili¬ 
zando un iterador. Se crea un iterador con el método 
create_iterador() proporcionado por la clase colección, 
como d_Set, igual que por la clase especial d_Extent, 
que se utiliza para acceder a la extensión de clase. 

En el código de la Figura 8.10, la línea 

d_Extent<Cliente>todos_los_clientes(bd_banco); 

declara todos_los_cl¡entes para ser una extensión de 
clase de la clase Cliente, y lo inicializa para ser la exten¬ 
sión de clase de Clientes en la base de datos bd_banco. 
A continuación la variable iter se establece para ser un 
iterador sobre los objetos en la extensión de clase de 
Cliente. 

El método next(), proporcionado por el iterador, se 
utiliza para avanzar por los elementos consecutivos de 
la colección de clientes. Para cada cliente se llama al 
método mostrar_clien (que se supone que se ha defini¬ 
do en alguna otra parte) para mostrar el cliente. 
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int mostrar_clientes (){ 

d_Database bd_banco_obj; 
d_Database * bcLbanco = &bd_banco_obj; 
bd_banco->open(«BD-Banco»); 
d_Transaction Trans; 

Trans.begin(); 

d_Extent<Cliente>todosJos_clientes(bcLbanco); 

dJterator<d_Ref<Cliente»iter=todosJos_cl¡entes.createJterator(); 
d_Ref<Cliente>p; 
while(iter.next(p)) { 
mostrar_clien(p); 

} 

Trans. commitQ; 


FIGURA 8.10. Ejemplo de utilización de los iteradores de C++ de ODMG. 


Las clases colección y la clase d_Extent proporcio¬ 
nan también un método select(), que es parecido a cre- 
ate_iterador(), pero toma una condición de selección 
como argumento, e itera solamente sobre aquellos obje¬ 
tos que satisfacen la condición de selección. 

8.5.2.3. Modificación de objetos 

Si un objeto va a ser modificado, la norma ODMG 
requiere que el sistema de bases de datos sea notifica¬ 
do del cambio. Para hacer esto, el programa debe invo¬ 
car al método mark_modified() sobre el objeto antes de 
que sea modificado. 

Por ejemplo, el método actual izar_saldo(d_Long del¬ 
ta) de la clase Cuenta debe invocar a mark_modified() 
antes de la actualización de su saldo. Si no se hace así 
puede que la actualización no se refleje en la base de 
datos. 

Hasta ahora, nuestro programa ejemplo sólo ha modi¬ 
ficado objetos que justo han sido creados, y no hay nece¬ 
sidad de invocar a mark_modified() para tales objetos. 
Los métodos definidos por el sistema como insert_ele- 
mentQ invocan automáticamente a mark_modified(). 

La necesidad de marcar los objetos como modifica¬ 
dos antes de modificarlos puede conducir a errores, pues¬ 
to que los programadores pueden olvidarse fácilmente 
de hacerlo. Algunas bases de datos orientadas a objetos 
implementan técnicas para determinar automáticamen¬ 
te cuándo se ha modificado un objeto, liberando al pro¬ 
gramador de esta tarea. 

5.5.2.4. Creación manual de extensión de clases 

Como ejercicio de escritura de un programa en la nor¬ 
ma ODMG, considérese cómo crear manualmente una 
extensión de clase para el objeto Cliente. Es conveniente 
guardar el identificador del conjunto en una variable 
global asociada con la clase Cliente. Se declara la varia¬ 
ble global añadiendo la siguiente línea como parte de 
la declaración de la clase Cliente. 

static d_Ref<d_Set<d_Ref<Cliente»> 
todos_los_cl ¡entes; 


Se asigna inicialmente el conjunto persistente de Clien¬ 
te en la base de datos y guarda su identificador en la 
variable global como sigue: 

Cliente::todos_los_clientes = 

new(bd_banco) d_Set<d_Ref<Cliente»; 

Cuando se crea un objeto Cliente, se inserta su identifi¬ 
cador en el conjunto de clientes utilizando una instruc¬ 
ción de la forma 

Cliente: :todos_los_clientes->insert_element(clien); 

Se puede crear un conjunto persistente para guardar los 
identificadores de los objetos Cuenta y guardar los iden- 
tificadores de los objetos cuenta en él de manera simi¬ 
lar. Sin embargo, el valor de la variable Clien- 
te::todos_los_clientes, y por tanto el identificador del 
conjunto persistente, desaparecería cuando finalizara la 
transacción. Para encontrar el conjunto en la base de 
datos más tarde, cuando se asigna inicialmente el con¬ 
junto se le da un nombre al identificador de objeto en 
la base de datos como sigue: 

bd_banco->set_object_nombre 

(Cliente: :todos_los_clientes,«Todos_los_clientes»); 

Cuando arranca una transacción posterior, primero abre 
la base de datos y a continuación busca el conjunto crea¬ 
do antes e inicializa Cliente::todos_los_clientes 

Cliente: :todos_los_clientes = 

bd_banco->lookup_object(«todos_los_clientes»); 

Una constructora de una clase es un método especial 
que se utiliza para inicializar los objetos cuando se crean; 
se llama de manera automática cuando se ejecuta el ope¬ 
rador new. De manera parecida, un destructor de una 
clase es un método especial que se llama cuando se 
borran los objetos de esa clase. Añadiendo la instruc¬ 
ción insert_element a las constructoras de una clase y 
la correspondiente instrucción delete_element a los des- 
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tructores de la clase, un programador puede asegurar 
que la colección Cliente::todos_los_clientes se man¬ 
tendrá de la manera adecuada. Como se observó en el 
Apartado 8.5.2.1, las implementaciones de la norma 
ODMG pueden mantener las extensiones de clases auto¬ 
máticamente, y de este modo no es necesario mante¬ 
nerlas manualmente. 

5.5.2.5. Lenguaje de consulta de objetos 

La norma ODMG proporciona el lenguaje de consultas 
declarativo OQL. OQL presenta el aspecto de SQL. El 
siguiente código crea y ejecuta una cuestión OQL para 
encontrar todas las cuentas pertenecientes a «Santos» 
cuyo saldo es mayor que 100. El resultado se guarda en 
la variable de tipo conjunto resultado. 

d_Set<d_Ref<Cuenta» resultado; 
d_OQL_Query ql («select a 

from Cliente c, c.cuentas a 
where c.nombre = ‘Santos’ 

and a.obtener_saldo() > 100»); 
d_oql_execute(q1 resultado); 

5.5.2.6. Cómo hacer transparente 
la persistencia de punteros 

Un inconveniente en el enfoque ODMG es que el pro¬ 
gramador tiene que tratar con dos tipos de punteros dife¬ 


rentes —punteros en memoria y referencias d_Ref— y 
el código que se escribe para un tipo no será válido para 
trabajar con el otro. Además, el programador tiene obli¬ 
gatoriamente que hacer la llamada mark_modified() 
cuando se modifique un objeto. 

En cambio, el sistema de bases de datos ObjectSto- 
re permite la referencia a los objetos de la base de datos 
utilizando el estilo de los punteros habituales en C++, 
en vez de utilizar d_Ref. Para el programador, los pun¬ 
teros a objetos persistentes son como los punteros a obje¬ 
tos en memoria habituales. La persistencia de punteros 
es transparente, y sólo tienen un tipo puntero que hacen 
la programación mucho más fácil. Los programadores 
de ObjectStore escriben los programas exactamente 
como con el lenguaje C++ habitual con la única dife¬ 
rencia de que, como en ODMG, los objetos pueden 
crearse en la base de datos utilizando una forma espe¬ 
cial de new. 

Esta funcionalidad se implementa a través de un 
mecanismo de traslación llamado rescate, que hace la 
conversión entre punteros persistentes y punteros a 
memoria; el rescate se describe en el Capítulo 11. 

El sistema de bases de datos ObjectStore también 
proporciona extensiones del lenguaje C++ que permite 
especificar más fácilmente las restricciones de integri¬ 
dad referencial. Los cambios también se detectan auto¬ 
máticamente y no requiere las llamadas a mark_modi- 
fied(). 


8.6. SISTEMAS JAVA PERSISTENTES 


En años recientes el lenguaje Java ha visto un enorme 
crecimiento en su uso. La demanda para permitir la per¬ 
sistencia de datos en los programas Java se ha incre¬ 
mentado correspondientemente, y el consorcio ODMG 
ha definido las normas para que se permita la persis¬ 
tencia en Java. 

El modelo ODMG para la persistencia de objetos en 
programas Java es diferente del modelo para la persis¬ 
tencia que se permite en programas C++. La mayor dife¬ 
rencia es el uso de la persistencia por alcance en Java. 
Los objetos no se crean explícitamente en la base de 
datos. En su lugar, se dan los nombres a los objetos en 
la base de datos que sirven como raíces para la persis¬ 
tencia. Estos objetos, y algunos objetos alcanzables des¬ 
de estos objetos, son persistentes. 

La persistencia por alcance implica que los punteros 
persistentes deben ser del mismo tipo que los punteros 
transitorios, por lo que no hay equivalencia de la clase 
plantilla de C++ d_Ref. Otro resultado de la persisten¬ 
cia por alcance es que los objetos en la base de datos 
pueden volverse basura si el objeto se vuelve inalcan¬ 
zable desde todas las raíces persistentes en la base de 
datos, y ninguna transacción activa guarda un puntero 
hacia el objeto. Tales objetos deben ser eliminados eje¬ 


cutando periódicamente un procedimiento de recogida 
de basura en la base de datos. La recogida de basura 
se efectúa generalmente de forma concurrente con otras 
actividades de la base de datos. 

Si un objeto de una clase se alcanza desde una raíz 
persistente, la clase se debe hacer persistente. Una cla¬ 
se normalmente se hace persistente (es decir, los obje¬ 
tos de esta clase pueden volverse persistentes) ejecu¬ 
tando un postprocesador en el código de la clase 
generado por la compilación del programa Java. Tam¬ 
bién es posible hacer persistente manualmente una cla¬ 
se insertando instrucciones apropiadas en el código Java, 
pero este enfoque es relativamente complicado y no se 
recomienda. 

El postprocesador también inserta código para mar¬ 
car automáticamente los objetos como modificados si 
son actualizados, a diferencia de la vinculación C++ de 
la norma ODMG en la que los objetos que se modifi¬ 
can se deben marcar explícitamente usando mark_modi- 
fied(). 

Cuando una transacción desea acceder a los objetos 
en la base de datos, se debe comenzar por uno de los 
objetos raíz de la base de datos que la transacción bus¬ 
ca por su nombre. El sistema va por el objeto raíz des- 
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de la base de datos en memoria. Las implementaciones 
pueden elegir ir a buscar todos los objetos referencia- 
dos inmediatamente desde el objeto raíz, o buscar los 
objetos referenciados de una forma perezosa. En una 
búsqueda perezosa de objetos, el objeto raíz es inicial¬ 
mente «vacío», es decir, se asigna una localización de 
memoria pero sus campos no se inicializan. Cuando se 
accede por primera vez un objeto vacío h, sus campos 
se rellenan desde la base de datos. El objeto vacío h pue¬ 
de contener referencias a otros objetos; si cualquiera de 


estos objetos se encuentra ya en memoria, sus direc¬ 
ciones en memoria se usan para reemplazar la referen¬ 
cia en h. Si el objeto referenciado no está en memoria, 
se crea para un objeto vacío ello, y la dirección en 
memoria del objeto vacío se usa para reemplazar la refe¬ 
rencia en h. 

La norma ODMG para Java define una colección de 
tipos tales como DSet, DBag y DList que extienden la 
colección de tipos estándar en Java. Java ya define un 
tipo iterador para iterar sobre colecciones. 


8.7. RESUMEN 


• Las aplicaciones de bases de datos de la generación 
actual no encajan a menudo en el conjunto de supo¬ 
siciones hecho para el tipo de aplicaciones más anti¬ 
guas de procesamiento de datos. Se ha desarrollado 
el modelo de datos orientado a objetos para trabajar 
con varios de estos nuevos tipos de aplicaciones. 

• El modelo de datos orientado a objetos es una adap¬ 
tación para los sistemas de bases de datos del para¬ 
digma de la programación orientada a objetos. Se basa 
en el concepto de encapsular los datos en un objeto y 
el código que opera sobre ellos. 

• De manera parecida, los objetos estructurados se agru¬ 
pan en clases. El conjunto de las clases se estructura 
en subclases y superclases basadas en una extensión 
del concepto ES del modelo entidad-relación. 

• El valor de un elemento de datos de un objeto puede 
ser un objeto, haciendo posible representar los conti¬ 
nentes de objetos, lo que da lugar a objetos com¬ 
puestos. 


• Hay dos enfoques para la creación de bases de datos 
orientadas a objetos: se pueden añadir los conceptos 
de la programación orientada a objetos a los lengua¬ 
jes de bases de datos existentes o extender los len¬ 
guajes orientados a objetos existentes para que tra¬ 
bajen con las bases de datos añadiendo conceptos 
como la persistencia y las colecciones. Las bases de 
datos relaciónales extendidas adoptan el primer enfo¬ 
que. Los lenguajes de programación persistentes adop¬ 
tan el segundo. 

• Las extensiones persistentes de C++ y Java han logra¬ 
do progresos significativos en los últimos años. La 
integración de la persistencia sin solución de conti¬ 
nuidad y de manera ortogonal con las constructoras 
de lenguajes existentes es importante para su facili¬ 
dad de uso. 

• La norma ODMG define clases y otras constructoras 
para la creación y acceso a los objetos persistentes 
desde C++ y Java. 


TÉRMINOS DE REPASO 


• Ambigüedad en la herencia 

• C++ ODL de ODMG 
— d_Ref, d_Set 

— Integridad referencial 
- _Ref_Sel, d_Ref_Ref 

• C++ ODL de ODMG 

— Extensión de Clase (d_Extent) 
— Iteradores (d_iterator) 

— Lenguaje de consulta de objetos 

• Clase 

• Clase más específica 

• Continente de objetos 

• Ejemplar 

• Encapsulamiento 


Grafo acíclico dirigido 
Herencia 
Herencia múltiple 
Identidad de objeto 

— Incorporada 

— Nombre 

— Valor 

identificador de objeto 
Jerarquía de clases 

Lenguajes de programación persistente 

Mensajes 

Métodos 

ObjectStore 
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Objeto 
ODMG Java 

— Persistencia por alcance 

— Raíces 

— Recogida de basura 
Papeles 

Persistencia por 

— Alcance 


— Clase 

— Creación 

— Marca 

Posibilidad de sustitución 

Subclase 

Superclase 

Variables 


EJERCICIOS 


8.1. Para cada una de las siguientes áreas de aplicación 
expliqúese la razón por la que no resultan apropiados 
los sistemas de bases de datos relaciónales. Indíquen- 
se todos los componentes específicos del sistema que 
habría que modificar. 

a. Diseño asistido por computadora. 

b. Bases de datos multimedia. 

8.2. ¿En qué se diferencian el concepto de objeto del mode¬ 
lo orientado a objetos y el concepto de entidad del 
modelo entidad-relación? 

8.3. Una compañía de alquiler de coches tiene una base de 
datos de los vehículos de su flota actual. Para todos los 
vehículos incluye el número de identificación de cada 
uno, el número de la matrícula, el fabricante, el mode¬ 
lo, la fecha de adquisición y el color. Se incluyen datos 
específicos para algunos tipos de vehículos: 

• Camiones: capacidad de carga. 

• Coches deportivos: potencia, requisitos de edad del 
conductor. 

• Camionetas: número de plazas. 

• Vehículos todo terreno: altura de los bajos, eje motor 
(tracción a dos o a las cuatro ruedas). 

Constrúyase la definición del esquema de una base de 
datos orientada a objetos para esta base de datos. Uti¬ 
lícese la herencia donde resulte conveniente 

8.4. Expliqúese el motivo de que pueda haber ambigüedad 
en caso de herencia múltiple. Ilústrese la explicación 
con un ejemplo. 

8.5. Expliqúese la diferencia entre el concepto de identidad 
de los objetos del modelo orientado a objetos y el con¬ 
cepto de igualdad de las tupias del modelo relacional. 


8.6. Expliqúese la diferencia de significado entre los arcos 
de un grafo dirigido acíclico que represente la heren¬ 
cia y un grafo dirigido acíclico que represente los con¬ 
tinentes de objetos. 

8.7. ¿Por qué permiten los lenguajes de programación per¬ 
sistentes los objetos transitorios? ¿Sería más sencillo 
utilizar sólo objetos persistentes y borrar los objetos no 
necesarios al concluir la ejecución? Expliqúese la res¬ 
puesta. 

8.8. Utilizando C++ de ODMG 

a. Dense definiciones de esquemas correspondientes 
al esquema relacional que se muestra en la Figura 
3.39 usando referencias para expresar las relaciones 
de clave externa. 

b. Escríbanse programas para resolver cada una de las 
cuestiones del ejercicio 3.10. 

8.9. Utilizando C++ de ODMG, dense definiciones de 
esquema correspondientes al diagrama E-R de la Figu¬ 
ra 2.29. Utilícense referencias para implementar las 
relaciones. 

8.10. Expliqúese, utilizando un ejemplo, cómo representar 
una relación ternaria en un modelo de datos orientado 
a objetos tal como C++ de ODMG. 

8.11. Expliqúese la manera en que se implementa un punte¬ 
ro persistente. Compárese esta implementación con la 
de los punteros de los lenguajes de propósito general, 
como C o Pascal. 

8.12. Si se crea un objeto sin que haya referencias al mismo, 
¿cómo se puede borrar? 

8.13. Considérese un sistema que proporcione objetos per¬ 
sistentes. ¿Se trata necesariamente de un sistema de 
bases de datos? Expliqúese la respuesta. 


NOTAS BIBLIOGRÁFICAS 


Las aplicaciones de los conceptos de las bases de datos 
a CAD se discuten en Haskin y Lorie [1982] y Lorie et 
al.[1985]. 

La programación orientada a objetos se discute en 
Goldberg y Robson [1983], Stefik y Bobrow [1986] y 


Stroustrup [1988]. Stroustrup [1997] describe el len¬ 
guaje de programación C++. 

Hay numerosos sistemas de bases de datos orienta¬ 
dos a objetos ya implementados, incluyendo (por orden 
alfabético) Cactis (Hudson y King [1989]); E/Exodus, 
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desarrollado en la Universidad de Wisconsin (Carey et 
al. [1990]); Gemstone (Maier et al. [1986]); Iris, desa¬ 
rrollado en Hewlett-Packard (Fishman et al. [1990]); 
Jasmine, desarrollado en los Laboratorios Fujitsu (Ishi- 
kawaet al. [1993]); 0 2 (Lecluseet al. [1988]); ObjectS- 
tore (Lamb et al. [1991]); Ode, desarrollado en los 
Laboratorios Bell (Agrawal y Gehani [1989]); Ontos; 
Open-OODB; Orion (Kim et al. [1988]); Versant y 
otros. 

La norma de bases de datos orientadas a objetos 
ODMG se describe con detalle en Cattell [2000]. 

En Kim [1990], Zdonik y Maier [1990] y Dogac et 
al. [1994] se pueden encontrar visiones de conjunto de 
la investigación en bases de datos orientadas a objetos. 


La identidad de objetos se caracteriza en detalle por 
Khoshafian y Copeland [1990]. 

La modificación de los esquemas en las bases de 
datos orientadas a objetos es más complicada que en las 
bases de datos relaciónales, dado que las bases de datos 
orientadas a objetos tienen sistemas de tipos complejos 
con herencia. La modificación de los esquemas se dis¬ 
cute en Skarra y Zdonik [1986], Banerjee et al. [1987] 
y en Penney y Stein [1987]. 

Goodman [1995] describe las ventajas y los inconve¬ 
nientes de utilizar bases de datos orientadas a objetos en 
una aplicación para la base de datos del genoma. Lunt [1995] 
proporciona una visión en conjunto de los aspectos de la 
autorización en las bases de datos orientadas a objetos. 
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BASES DE DATOS RELACIONALES 
ORIENTADAS A OBJETOS 


L os lenguajes de programación persistentes añaden la persistencia y otras características 
de las bases de datos a los lenguajes de programación existentes con sistemas de tipos 
orientados a objetos. Por el contrario, los modelos de datos relaciónales orientados a 
objetos extienden el modelo de datos relacional proporcionando un sistema de tipos más rico 
e incluyendo tipos de datos complejos y la programación orientada a objetos. Los lenguajes de 
consulta relaciónales como SQL también necesitan ser extendidos para trabajar con el sistema 
de tipos enriquecido. Estas extensiones intentan conservar los fundamentos relaciónales —en 
concreto, el acceso declarativo a los datos— al tiempo que extienden la capacidad de modela¬ 
do. Los sistemas de bases de datos relaciónales orientados a objetos (es decir, los sistemas de 
bases de datos basados en el modelo objeto-relación) proporcionan un modo de cambio ade¬ 
cuado para los usuarios de las bases de datos relaciónales que deseen utilizar características 
orientadas a objetos. 

En primer lugar, se presenta la motivación del modelo relacional anidado, que permite rela¬ 
ciones que no cumplen la primera forma normal y permite la representación directa de las estruc¬ 
turas jerárquicas. Posteriormente se muestra la manera de extender SQL añadiendo varias 
características relaciónales orientadas a objetos. El estudio se basa en la norma SQL: 1999. 

Finalmente se analizan las diferencias entre los lenguajes de programación persistentes y los 
sistemas relaciónales orientados a objetos y se mencionan los criterios para la elección entre 
unos y otros. 


9.1. RELACIONES ANIDADAS 


En el Capítulo 7 se definió la primera forma normal 
(1FN), que exige que todos los atributos tengan domi¬ 
nios atómicos. Un dominio es atómico si los elementos 
del mismo se consideran unidades indivisibles. 

La suposición de 1FN es natural en el ejemplo ban- 
cario considerado en capítulos anteriores. Sin embargo, 
no todas las aplicaciones se modelan de la mejor forma 
con relaciones 1FN. Por ejemplo, en lugar de ver la base 
de datos como un conjunto de registros, los usuarios de 
ciertas aplicaciones deben tratarla como un conjunto de 
objetos (o entidades). Estos objetos pueden requerir una 
correspondencia uno a uno entre la noción intuitiva del 
usuario de un objeto y la noción del sistema de bases 
de datos de un elemento de datos. 

El modelo relacional anidado es una extensión del 
modelo relacional en la que los dominios pueden ser ató¬ 


micos o de relación. Por tanto, el valor de las tupias de los 
atributos puede ser una relación, y las relaciones pueden 
guardarse en otras relaciones. Los objetos complejos, por 
tanto, pueden representarse mediante una única tupia de 
las relaciones anidadas. Si se consideran las tupias de las 
relaciones anidadas como elementos de datos, se tiene una 
correspondencia uno a uno entre los elementos de datos 
y los objetos de la vista de la base de datos del usuario. 

Las relaciones anidadas se ilustran mediante un ejem¬ 
plo extraído de una biblioteca. Considérese que para 
cada libro se almacena la información siguiente: 

• Título del libro 

• Lista de autores 

• Editorial 

• Lista de palabras clave 


título 

lista-autores 

editorial 

(nombre , sucursal) 

lista-palabras-clave 

Compiladores 

{Gómez, Santos} 

(McGraw-Hill, Nueva York) 

{traducción, análisis} 

Redes 

{Santos, Escudero} 

(Oxford, Londres) 

{Internet, Web} 


FIGURA 9.1. La relación de documentos libros que no está en 1FN. 
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Puede verse que, si se define una relación para la 
información anterior, varios de los dominios serán no 
atómicos. 

• Autores. Un libro puede tener varios autores. No 
obstante, puede que se desee hallar todos los docu¬ 
mentos entre cuyos autores estuviera Santos. Por 
tanto, hay interés en una parte del elemento del 
dominio «conjunto de autores». 

• Palabras clave. Si se guarda un conjunto de pala¬ 
bras clave de cada documento se espera poder recu¬ 
perar todos los documentos cuyas claves incluyan 
una o varias de las palabras clave especificadas. 
Por tanto, se considera que el dominio de la lista 
de palabras clave no es atómico. 

• Editorial. A diferencia de palabras clave y auto¬ 
res , editorial no tiene un dominio de tipo conjun¬ 
to. Sin embargo, se puede considerar que editorial 
consiste en los subcampos nombre y sucursal. Esta 
manera de considerarlo hace que el dominio de 
editorial no sea atómico. 

En la Figura 9.1 se muestra un ejemplo de la rela¬ 
ción de documentos libros. La relación libros puede 
representarse en 1FN como se muestra en la Figura 9.2. 
Dado que en 1FN hay que disponer de dominios ató¬ 
micos pero se desea tener acceso a los diferentes auto¬ 
res y palabras clave, hace falta una tupia para cada par 
(palabra clave, autor). El atributo editorial se sustituye 
en la versión 1FN por dos atributos: uno por cada sub¬ 
campo de editorial. 


Gran parte de la incomodidad de la relación libros- 
planos de la Figura 9.2 se elimina si se supone que se 
cumplen las dependencias multiv al oradas siguientes: 

título —»-> autor 

título —»-> palabra-clave 

título —* nombre-editorial , sucursal-editorial 

Por tanto, se puede descomponer la relación en 4FN 
utilizando los esquemas: 

autores(título, autor) 

palabras-claveltítulo, palabra-clave) 

libros4(título, nombre-editorial, sucursal-editorial) 

En la Figura 9.3 se muestra la proyección de la rela¬ 
ción libros-planos de la Figura 9.2 en la descomposi¬ 
ción anterior. 

Aunque el ejemplo de la base de datos de libros se 
puede expresar adecuadamente sin usar relaciones ani¬ 
dadas, su uso conduce a un modelo más fácil de com¬ 
prender, dado que el usuario típico de los sistemas de 
recuperación de información piensa en la base de datos 
en términos de libros que tienen una lista de autores, como 
los modelos de diseño que no están en 1FN. El diseño 
4FN necesita que los usuarios incluyan reuniones en las 
consultas, lo que complica la interacción con el sistema. 

Se puede definir una vista relacional no anidada (cuyo 
contenido sea indéntico a libros-planos) que elimine la 
necesidad de que los usuarios escriban reuniones en las 
consultas. En esa vista, sin embargo, se pierde la corres¬ 
pondencia uno a uno entre las tupias y los documentos. 


título 

autor 

nombre-editorial 

sucursal-editorial 

palabra-clave 

Compiladores 

Gómez 

McGraw-HIII 

Nueva York 

traducción 

Compiladores 

Santos 

McGraw-HIII 

Nueva York 

traducción 

Compiladores 

Gómez 

McGraw-HIII 

Nueva York 

análisis 

Compiladores 

Santos 

McGraw-HIII 

Nueva York 

análisis 

Redes 

Santos 

Oxford 

Londres 

Internet 

Redes 

Escudero 

Oxford 

Londres 

Internet 

Redes 

Santos 

Oxford 

Londres 

Web 

Redes 

Escudero 

Oxford 

Londres 

Web 


FIGURA 9.2. libros-planos, una versión 1FN de la relación libros que no estaba en 1FN. 


9.2. TIPOS COMPLEJOS 


Las relaciones anidadas son sólo un ejemplo de las 
extensiones del modelo relacional básico. Otros tipos 
de datos no atómicos, como los registros anidados, 
también se han mostrado útiles. El modelo de datos 
orientado a objetos ha creado la necesidad de carac¬ 
terísticas como la herencia y las referencias a los obje¬ 
tos. Los sistemas de tipos complejos y la programa¬ 
ción orientada a objetos permiten que los conceptos 
del modelo E-R, como la identidad de las entidades, 
los atributos multivalorados y la generalización y la 


especialización, se representen directamente sin que 
haga falta una compleja traducción al modelo rela¬ 
cional. 

En este apartado se describen las extensiones de SQL 
para que permita los tipos complejos, incluyendo las 
relaciones anidadas y las características orientadas a 
objetos. La presentación se basa en la norma SQL: 1999, 
pero también se describen características que no están 
actualmente en la norma pero que pueden ser introdu¬ 
cidas en futuras versiones de la norma SQL. 
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título 

autor 

Compiladores 

Compiladores 

Redes 

Redes 

Gómez 

Santos 

Santos 

Escudero 


autores 


título 

palabra-clave 

Compiladores 

Compiladores 

Redes 

Redes 

beneficios 

estrategia 

beneficios 

personal 


palabras-clave 


título 

nombre-editorial 

sucursal-editorial 

Compiladores 

Redes 

McGraw-HIII 

Oxford 

Nueva York 
Londres 


libros4 


FIGURA 9.3. Versión 4FN de la relación libros-planos de la 
Figura 9.2. 


9.2.1. Tipos colección y tipos de objetos 
de gran tamaño 

Considérese este fragmento de código, 
create table libros ( 

lista-palabras-clave setof(varchar(20)) 

) 

Esta definición de tabla es diferente de las defini¬ 
ciones en las bases de datos relaciónales normales, ya 
que permite que los atributos sean conjuntos, permi¬ 
tiendo que los atributos multivalorados de los diagra¬ 
mas E-R se representen directamente. 

Los conjuntos son ejemplares de los tipos colección. 
Otros ejemplares son los arrays y los muíticonjuntos 
(es decir, colecciones sin orden donde un elemento pue¬ 
de aparecer varias veces). Las siguientes definiciones 
de atributos ilustran la declaración de un array. 

array-autores varchar(20) array [10] 

array-autores es un array de hasta 10 nombres de autor. 
Se puede acceder a los elementos del array especifican¬ 
do el índice del array, por ejemplo, array-autores[ 1]. 

Los arrays son el único tipo colección soportado en 
SQL: 1999; la sintaxis usada es como en la declaración 
precedente. SQL: 1999 no da soporte a conjuntos sin 
orden o multiconjuntos, aunque es posible que aparez¬ 
can en versiones futuras de SQL 1 . 

Muchas aplicaciones actuales de bases de datos nece¬ 
sitan almacenar atributos grandes (del orden de varios 


kilobytes), tales como la fotografía de una persona, o 
muy grandes (del orden de varios megabytes o incluso 
gigabytes), tales como imágenes médicas de alta reso¬ 
lución o clips de vídeo. SQL: 1999 proporciona por tan¬ 
to nuevos tipos de datos para objetos de gran tamaño 
para datos de caracteres (clob) y binarios (blob). Las 
letras «lob» en estos tipos de datos son acrónimos de 
«Large OBject» (objeto grande). Por ejemplo, se pue¬ 
den declarar los siguientes atributos: 

crítica-libro clob(lOKB) 
imagen blob(lOMB) 
película blob(2GB) 

Los objetos grandes se usan normalmente en apli¬ 
caciones externas, y tiene poco sentido extraerlos com¬ 
pletamente en SQL. En su lugar, una aplicación conse¬ 
guiría un «localizador» de un objeto grande y lo usaría 
para manipularlo desde el lenguaje anfitrión. Por ejem¬ 
plo, JDBC permite al programador extraer un objeto 
grande en pequeños trozos, en lugar de todo a la vez, 
de forma muy parecida a la extracción de datos de un 
archivo del sistema operativo. 

9.2.2. Tipos estructurados 

Los tipos estructurados se pueden declarar y usar en 
SQL: 1999 como en el siguiente ejemplo: 

create type Editorial as 
(,nombre varchar(20), 
sucursal varchar(20)) 
create type Libro as 
(,título varchar(20), 
array-autores varchar(20) array [10], 
feclia-pub date, 
editorial Editorial, 

lista-palabras-clave setof(varchar(20))) 
create table libros of type Libro 

La primera instrucción define el tipo Editorial, que tie¬ 
ne dos componentes: un nombre y una sucursal. La segun¬ 
da instrucción define el tipo Libro, que contiene título, 
array-autores, que es un array de autores, una fecha de 
publicación, una editorial (de tipo Editorial) y un con¬ 
junto de palabras clave. (La declaración de lista-palabras- 
clave como un conjunto usa la sintaxis extendida y no está 
soportada en la norma SQL: 1999.) Los tipos ilustrados se 
denomina tipos estructurados en SQL: 1999. 

Linalmente, se crea la tabla libros que contiene tupias 
del tipo Libro. La tabla es similar a la relación anidada libros 
de la Ligura 9.1, excepto en que se ha decidido crear un 
array de nombres de autores en lugar de un conjunto. El 
array permite registrar el orden de los nombres de autores. 

Los tipos estructurados permiten la representación 
directa de atributos compuestos de los diagramas E-R. 
También se pueden usar tipos fila en SQL: 1999 para 


1 El sistema de bases de datos Oracle 8 soporta relaciones anidadas, 
pero usa una sintaxis diferente de la de este capítulo. 


213 
















FUNDAMENTOS DE BASES DE DATOS 


definir atributos compuestos. Por ejemplo, se podría 
haber definido un atributo editoriall como 

editoriall row ( nombre varchar(20), 
sucursal varchar(29)) 

en lugar de crear un tipo con nombre Editorial. 

Por supuesto se pueden crear tablas sin crear un tipo 
intermedio para la tabla. Por ejemplo, la tabla libros se 
podría también definir como: 

create table libros 

(;título varchar(20), 
array-autores varchar(20) array [10], 
fecha-pub date, 
editorial Editorial, 

lista-palabras-clave setof(varchar(20))) 

Con esta declaración no hay un tipo explícito para las 
filas de la tabla 2 . 

Un tipo estructurado puede tener métodos definidos 
sobre él. Los métodos se declaran como parte de la defi¬ 
nición de tipos de un tipo estructurado. 

create type Empleado as ( 
nombre varchar(20), 
sueldo integer) 

method incrementar(porcentaje integer) 

El cuerpo del método se crea separadamente: 

create method incrementar(porcentaje integer) 
for Empleado 

begin 

set selft.sueldo = self.sueldo + (self.sueldo* 
porcentaje)/100 

end 

La variable self se refiere al ejemplar del tipo estructu¬ 
rado sobre el que se invoca el método. El cuerpo del 
método puede contener instrucciones procedimentales, 
que se estudiarán en el Apartado 9.6. 

9.2.3. Creación de valores de tipos complejos 

En SQL: 1999 se usan las funciones constructoras para 
crear valores de tipos estructurados. Una función con el 
mismo nombre que un tipo estructurado es una función 
constructora para el tipo estructurado. Por ejemplo, se podría 
declarar una constructora para el tipo Editorial como: 

create function Editorial (n varchar(20), 5 varchar(20)) 

returns Editorial 

begin 

set nombre = n\ 
set sucursal = s ; 

end 


Se puede usar entonces Editorial^ McGraw-Hill’, ‘Nue¬ 
va York’) para crear un valor del tipo Editorial. 

SQL: 1999 también soporta otras funciones además 
de las constructoras, como se verá en el Apartado 9.6; 
los nombres de estas funciones deben ser diferentes de 
cualquier tipo estructurado. 

Nótese que en SQL: 1999, a diferencia de en las bases 
de datos orientadas a objetos, un constructor crea un valor 
del tipo, no un objeto del tipo. Es decir, el valor que crea 
el constructor no tiene identidad de objeto. Los objetos 
en SQL: 1999 se corresponden con tupias de una relación, 
y se crean insertando tupias en las relaciones. 

De manera predeterminada, cada tipo estructurado 
tiene un constructor sin argumentos, que establece los 
atributos a sus valores predeterminados. Cualquiera otra 
constructora tiene que crearse explícitamente. Puede 
haber más de una constructora para el mismo tipo estruc¬ 
turado; aunque tengan el mismo nombre, tienen que ser 
distinguibles por el número de argumentos y sus tipos. 

En SQL: 1999 se puede crear un array de valores 
como: 

array[‘Silberschatz’, ‘Korth’, ‘Sudarsan’] 

Se puede construir un valor de fila listando sus atribu¬ 
tos entre paréntesis. Por ejemplo, si se declara un atri¬ 
buto editoriall como un tipo fila (como en el Apartado 
9.2.2), se puede construir el siguiente valor para él: 

(‘McGraw-Hill’, ‘Nueva York’) 
sin usar una constructora. 

Los atributos de tipo conjunto, tales como lista-pala¬ 
bras-clave, se crean enumerando sus elementos entre 
paréntesis siguiendo a la palabra clava set. Se pueden 
crear valores de tipo multiconjunto al igual que con los 
valores de tipo conjunto, reemplazando set por multiset 3 . 

Así, se puede crear una tupia del tipo definido por la 
relación libros como: 

(‘ Compiladores ’,array [ ‘ Gómez ’, ‘ S antos ’ ], 
Editorial^ McGraw-Hill’, ‘Nueva York’), 
set(‘ traducción, análisis’)) 

Aquí se ha creado un valor para el atributo Editorial 
invocando a la función constructora de Editorial con 
argumentos apropiados. 

Si se desea insertar la tupia anterior en la relación 
libros, se podría ejecutar la instrucción: 

insert into libros 
valúes 

(‘ Compiladores’,array[ ‘ Gómez ’, ‘ Santos’ ], 
Editorial^ McGraw-Hill’, ‘Nueva York’), 
set(‘ traducción, análisis’)) 


3 Aunque los conjuntos y multiconjuntos no son parte de la norma 
SQL: 1999, las otras constructoras mostradas en este apartado sí lo 
son. Las versiones futuras de SQL probablemente darán soporte a 
los conjuntos y multiconjuntos. 


2 En PL/SQL de Oracle, dada una tabla f, í%rowtype denota el tipo 
de las ñlas de la tabla. De forma similar, f.a%type denota el tipo del 
atributo a de la tabla t. 
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9.3. HERENCIA 


La herencia puede hallarse en el nivel de los tipos o en 
el nivel de las tablas. En primer lugar se considerará la 
herencia de los tipos y después en el nivel de las tablas. 

9.3.1. Herencia de tipos 

Supóngase que se dispone de la siguiente definición de 
tipos para las personas: 

create type Persona 

(,nombre varchar(20), 
dirección varchar(20)) 

Puede que se desee guardar en la base de datos más 
información sobre las personas que sean estudiantes y 
sobre las que sean profesores. Dado que los estudian¬ 
tes y los profesores también son personas, se puede uti¬ 
lizar la herencia para definir los tipos estudiante y pro¬ 
fesor en SQL: 1999: 

create type Estudiante 
under Persona 
(curso varchar(20), 
departamento varchar(20)) 
create type Profesor 
under Persona 
(sueldo integer, 
departamento varchar(20)) 

Tanto Estudiante como Profesor heredan los atributos de 
Persona, es decir, nombre y dirección. Estudiante y Pro¬ 
fesor se denominan subtipos de Persona y ésta, a su vez, 
es un supertipo de Estudiante y de Profesor. 

Los métodos de un tipo estructurado se heredan por 
sus subtipos, al igual que los atributos. Sin embargo, un 
subtipo puede redefinir el efecto de un método decla¬ 
rando de nuevo el método, usando overriding method 
en lugar de method en la declaración del método. 

Supóngase ahora que se desea guardar la informa¬ 
ción sobre los ayudantes, que son simultáneamente estu¬ 
diantes y profesores, quizás incluso en departamentos 
diferentes. Esto se puede hacer usando la herencia múl¬ 
tiple, que se estudió en el Capítulo 8. La norma 
SQL: 1999 no soporta herencia múltiple. Sin embargo, 
los borradores de la norma sí lo hacían, y aunque la nor¬ 
ma final la omitió, versiones futuras de la norma SQL 
pueden introducirla. Lo que se expone a continuación 
se basa en los borradores de la norma. 

Por ejemplo, si el sistema de tipos permite la heren¬ 
cia múltiple, se puede definir un tipo para los ayudan¬ 
tes de la manera siguiente: 


Ayudante heredaría todos los atributos de Estudiante y 
de Profesor. Surge un problema, sin embargo, dado que 
los atributos nombre, dirección y departamento se hallan 
presentes en Estudiante y en Profesor. 

Los atributos nombre y dirección se heredan en rea¬ 
lidad de un origen común, Persona. Así que no se pro¬ 
voca ningún conflicto al heredarlos de Estudiante y de 
Profesor. Sin embargo, el atributo departamento se 
define de manera separada en Estudiante y en Profe¬ 
sor. De hecho, los ayudantes pueden ser estudiantes 
de un departamento y profesores de otro. Para evitar 
un conflicto entre los dos ejemplares de departamen¬ 
to se les puede cambiar el nombre utilizando una ins¬ 
trucción as como se muestra en la siguiente definición 
del tipo Ayudante: 

create type Ayudante 

under Estudiante with (departamento as 
dep-estudiante ) 

Profesor with (departamento as 
dep-profesor) 

SQL: 1999 sólo soporta herencia única, es decir, un 
tipo puede heredar de sólo un tipo único; la sintaxis 
usadas es como en los ejemplos anteriores. La heren¬ 
cia múltiple como en el ejemplo Ayudante no está 
soportada en SQL: 1999. La norma SQL: 1999 también 
requiere un campo extra al final de la definición de 
tipos, cuyo valor es final o not final. La palabra cla¬ 
ve final dice que los subtipos no se pueden crear des¬ 
de el tipo dado, mientras que not final dice que se 
pueden crear. 

En SQL, como en la mayor parte de los lenguajes de 
programación, las entidades deben tener exactamente 
un tipo más específico. Es decir, cada valor debe estar 
asociado con un tipo específico, denominado tipo más 
específico, cuando se crea. Mediante la herencia tam¬ 
bién se asocia con cada uno de los supertipos de su tipo 
más específico. Por ejemplo, supóngase que una enti¬ 
dad tiene el tipo Persona y el tipo Estudiante. Por tan¬ 
to, el tipo más específico de la entidad es Estudiante, 
dado que Estudiante es un subtipo de Persona. Sin 
embargo, una entidad no puede tener los tipos Estu¬ 
diante y Profesor, a menos que tenga un tipo, como Ayu¬ 
dante, que sea un subtipo de Profesor y de Estudiante. 

9.3.2. Herencia de tablas 

Las subtablas en SQL: 1999 se corresponden con la 
noción del modelo E-R de la especialización y la gene¬ 
ralización. Por ejemplo, supóngase que se define la tabla 
personas de la manera siguiente: 


create type Ayudante 

under Estudiante, Profesor 
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Se pueden definir entonces las tablas estudiantes y pro¬ 
fesores como subtablas de persona : 

create table estudiantes of Estudiante 
under persona 

create table profesores of Profesor 
under persona 

Los tipos de las subtablas deben ser subtipos del tipo de 
la tabla padre. Por tanto, cada atributo presente en per¬ 
sona debe estar también presente en las subtablas. 

Además, cuando se declaran estudiantes y profeso¬ 
res como subtablas de persona , cada tupia presente en 
estudiantes o profesores también están presentes implí¬ 
citamente en persona. Así, si una consulta usa la tabla 
persona, encontrará no sólo las tupias insertadas direc¬ 
tamente en la tabla, sino también las tupias insertadas 
en sus subtablas estudiantes y profesores. Sin embargo, 
sólo se puede acceder a los atributos que están presen¬ 
tes en persona. 

Es posible la herencia múltiple con las tablas, como 
con los tipos. (Nótese, sin embargo, que la herencia múl¬ 
tiple de tablas no se soporta en SQL: 1999.) Por ejem¬ 
plo, se puede crear una tabla del tipo Ayudante: 

create table ayudantes 
of Ayudante 

under estudiantes, profesores 

Como resultado de la declaración, cada tupia presente 
en la tabla ayudantes también está presente implícita¬ 
mente en las tablas profesores y estudiantes, y a su vez 
en la tabla persona. 

SQL: 1999 permite buscar tupias que estén en per¬ 
sona pero no en sus subtablas usando «only persona» 
en lugar de persona en la consulta. 

Hay algunos requisitos de consistencia para las sub¬ 
tablas. Antes de indicar las restricciones es necesaria 
una definición: se dice que las tupias de una subtabla 
corresponden a las tupias de una tabla padre si tienen 
los mismo valores para todos los atributos heredados. 
Así, las tupias correspondientes representan la misma 
entidad. 

Los requisitos de consistencia para las subtablas son: 

1. Cada tupia de la supertabla puede corresponder 
a lo sumo con una tupia de cada una de sus tablas 
inmediatas. 

2. SQL: 1999 tiene una restricción adicional que esta¬ 
blece que todas las tupias que se correspondan se 
deben derivar de una tupia (insertada en una 
tabla). 

Por ejemplo, sin la primera condición se podrían tener 
dos tupias en estudiantes (o en profesores) correspon¬ 
diente a la misma persona. 

La segunda condición descarta una tupia en perso¬ 
na correspondiente a tupias de estudiantes estudiantes 


y profesores, a menos que esas tupias estén presentes 
implícitamente porque se insertó una tupia en la tabla 
ayudantes, que es una subtabla de profesores y estu¬ 
diantes. 

Dado que SQL: 1999 no soporta herencia múltiple, 
la segunda condición realmente impide que una perso¬ 
na sea tanto profesor como estudiante. El mismo pro¬ 
blema surgiría si no existiese la subtabla ayudantes, 
incluso si hubiese herencia múltiple. Obviamente sería 
útil modelar una situación donde una persona pueda ser 
profesor y estudiante, incluso si no está presente la sub¬ 
tabla común ayudantes. Por tanto, puede ser útil elimi¬ 
nar la segunda restricción de consistencia. Se volverá a 
este tema en el Apartado 9.3.3. 

Las subtablas pueden guardarse de manera eficien¬ 
te sin réplica de todos los campos heredados de una de 
las dos siguientes formas: 

• Cada tabla almacena la clave primaria (que se pue¬ 
de heredar de una tabla padre) y los atributos defi¬ 
nidos localmente. Los atributos heredados (apar¬ 
te de la clave primaria) no hace falta guardarlos y 
pueden obtenerse mediante una reunión con la 
supertabla basada en la clave primaria. 

• Cada tabla almacena todos los atributos heredados 
y definidos localmente. Cuando se inserta una tupia 
se almacena sólo en la tabla en la que se inserta y 
su presencia se infiere en cada supertabla. El acce¬ 
so a todos los atributos de una tupia es más rápi¬ 
do, dado que no se requiere una reunión. Sin 
embargo, en el caso de que no se considere la 
segunda restricción de integridad —es decir, una 
entidad se puede representar en dos subtablas sin 
estar presente en una subtabla común de ambas— 
esta representación puede resultar en duplicación 
de información. 

9.3.3. Solapamiento de subtablas 

La herencia de tipos debe utilizarse con precaución. Una 
base de datos universitaria puede tener muchos subti¬ 
pos de Persona, como Estudiante, Profesor, Jugador- 
DeFútbol, CiudadanoExtranjero, etcétera. Estudiante 
puede a su vez tener subtipos como EstudianteDeDi- 
plomatura, EstudianteDeLicenciatura y EstudianteA- 
TiempoParcial. Evidentemente, una persona puede per¬ 
tenecer a varias de estas categorías simultáneamente. 
Como se mencionó en el Capítulo 8, a veces se deno¬ 
mina papel a cada una de estas categorías. 

Para que cada entidad tenga exactamente un tipo más 
específico habría que crear un subtipo para cada combi¬ 
nación posible de los supertipos. En el ejemplo anterior 
habría subtipos como EstudianteDeDiplomaturaEx- 
tranjero, EstudianteDeLicenciaturaJugadorDeFútbo- 
lExtranjero, etcétera. Lamentablemente, se acabaría con 
un número enorme de subtipos de Persona. 

Un enfoque mejor en el contexto de los sistemas de 
bases de datos es permitir que un objeto tenga varios 
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tipos, sin que tenga un tipo más específico. Los siste¬ 
mas relaciónales orientados a objetos pueden modelar 
esta característica utilizando la herencia en el nivel de 
las tablas, en vez de en el nivel de los tipos, y permi¬ 
tiendo que las entidades estén en más de una tabla simul¬ 
táneamente. 

Por ejemplo, supóngase de nuevo que se tiene el tipo 
Persona con los subtipos Estudiante y Profesor, y la 
tabla correspondiente persona, con subtablas profeso¬ 
res y estudiantes. Se puede entonces tener una tupia en 
profesores y otra en estudiantes que correspondan a la 
misma tupia en persona. 

No hay necesidad de tener un tipo Ayudante como 
subtipo de Estudiante y Profesor. No es necesario crear 


el tipo Ayudante a menos que se desee almacenar atri¬ 
butos extra o redefinir métodos de específicamente para 
las personas que sean estudiantes y profesores. 

Sin embargo, SQL: 1999 prohíbe esta situación 
debido al requisito de consistencia 2 del Apartado 
9.3.2. Dado que SQL: 1999 no soporta herencia múl¬ 
tiple, no se puede usar la herencia para modelar una 
situación donde una persona pueda ser estudiante y 
profesor. Por supuesto se pueden crear tablas separa¬ 
das para representar la información sin usar la heren¬ 
cia. Habría que añadir restricciones de integridad refe- 
rencial apropiadas para asegurar que los estudiantes 
y profesores están representados también en la tabla 
persona. 


9.4. TIPOS DE REFERENCIA 


Los lenguajes orientados a objetos proporcionan la 
posibilidad de hacer referencia a los objetos. El atri¬ 
buto de un tipo puede ser una referencia a un objeto 
de un tipo especificado. Por ejemplo, en SQL: 1999 
se puede definir un tipo Departamento, con campos 
nombre y director, que es una referencia al tipo Per¬ 
sona, y una tabla departamentos de tipo Departa¬ 
mento, como sigue: 

create type Departamento ( 
nombre varchar(20), 
director vdi( Persona) scope persona 

) 

create table departamentos of Departamento 

La referencia en este ejemplo está restringida a tupias 
de la tabla persona. La restricción de scope de una refe¬ 
rencia a las tupias de una tabla es obligatoria en 
SQL: 1999 y hace que las referencias se comporten como 
claves externas. 

Se puede omitir la declaración scope persona de la 
declaración de tipos y en su lugar añadirla a la instruc¬ 
ción create table. 

create table departamentos of Departamento 
(i director with options scope persona ) 

Para inicializar un atributo referencia es necesario 
obtener el identificador de la tupia a la que se va a hacer 
referencia. Se puede obtener el valor del identificador 
de una tupia mediante una consulta. Así, para crear una 
tupia con el valor referencia, se puede crear en primer 
lugar la tupia con una referencia nula y después esta¬ 
blecer la referencia: 

inserí into departamentos 
valúes (‘Informática’, nuil) 
update departamentos 


set director = (select ref(p) 

from persona as p 
where nombre = ‘Juan’) 
where nombre = ‘Informática’ 

Esta sintaxis para acceder al identificador de una tupia 
está basada en la sintaxis de Oracle. SQL: 1999 adopta 
un enfoque diferente, en el que la tabla referenciada 
debe tener un atributo que almacene el identificador de 
la tupia. Este atributo, denominado atributo autorre- 
ferencial, se declara añadiendo la cláusula ref is a la 
instrucción create table. 

create table persona of Persona 

ref is ido system generated 

Donde ido es un nombre de atributo, no una palabra cla¬ 
ve. La subconsulta anterior podría usar 

select p.ido 

en lugar de select ref(p). 

Una alternativa a los identificadores generados por 
el sistema es permitir a los usuarios generar identifica¬ 
dores. El tipo del atributo autorreferencial se debe espe¬ 
cificar como parte de la definición de tipos de la tabla 
referenciada, y la definición de tabla debe especificar 
que la referencia la genera el usuario (user generated). 

create type Persona 

(nombre varchar(20), 
dirección varchar(20)) 
ref using varchar(20) 
create table persona of Persona 
ref is ido user generated 

Al insertar una tupia en persona se debe proporcio¬ 
nar un valor para el identificador: 
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insert into persona valúes 

(‘01284567’, ‘Juan’, ‘Plaza Mayor, 1’) 

Ninguna otra tupia de persona o sus supertablas pue¬ 
den tener el mismo identificador. Se puede entonces usar 
el valor del identificador al insertar una tupia en depar¬ 
tamentos, , sin necesitar una consulta separada para obte¬ 
ner el identificador. 

insert into departamentos 

valúes (‘Informática’, ‘01284567’) 

Es posible incluso usar un valor existente de clave 
primaria como identificador, incluyendo la cláusula ref 
from en la definición de tipos: 


create type Persona 

(,nombre varchar(20) primary key, 
dirección varchar(20)) 
ref from nombre 
create table persona of Persona 
ref is ido derived 

Nótese que la definición de tabla debe especificar que 
la referencia es derivada y aún debe especificar un nom¬ 
bre de atributo autorreferencial. Al insertar una tupia en 
departamentos , se puede usar: 

insert into departamentos 

valúes (‘Informática’, ‘Juan’) 


9.5. CONSULTAS CON TIPOS COMPLEJOS 


En este apartado se presenta una extensión del lengua¬ 
je de consulta SQL para trabajar con los tipos com¬ 
plejos. Se puede comenzar por un ejemplo sencillo: 
averiguar el título y el nombre de la editorial de cada 
documento. La consulta siguiente lleva a cabo esa 
tarea: 

select título, editorial.nombre 
from libros 

Obsérvese que se hace referencia al campo nombre del 
atributo compuesto editorial utilizando una notación 
con un punto. 

9.5.1. Expresiones de ruta 

Las referencias se desreferencian en SQL: 1999 con el 
símbolo ->. Considérese otra vez la tabla departamen¬ 
tos. Se puede usar la siguiente consulta para hallar los 
nombres y direcciones de los directores de todos los 
departamentos. 

select director->nombre, director->dirección 
from departamentos 

Una expresión como «director->nombre» se denomi¬ 
na una expresión de ruta. 

Dado que director es una referencia a una tupia de 
la tabla persona, el atributo nombre en la consulta ante¬ 
rior es el atributo nombre de la tupia de la tabla perso¬ 
na. Se pueden usar las referencias para ocultar las ope¬ 
raciones reunión; en el ejemplo anterior, sin las 
referencias, el campo director de departamento se decla¬ 
raría como clave externa de la tabla persona. Para encon¬ 
trar el nombre y dirección del director de un departa¬ 
mento se necesitaría una reunión explícita de las 
relaciones departamentos y persona. El uso de refe¬ 
rencias simplifica considerablemente la consulta. 


9.5.2. Atributos de tipo colección 

Ahora se considera la forma de manejar los atributos de 
tipo colección. Los arrays son el único tipo colección 
soportado por SQL: 1999, pero también se usa la mis¬ 
ma sintaxis para los atributos de tipo relación. Una 
expresión que se evalúe a una colección puede apare¬ 
cer en cualquier lugar en que aparezca un nombre de 
relación, tal como en la cláusula from, como ilustran 
los siguientes párrafos. Se usa la tabla libros que se defi¬ 
nió anteriormente. 

Si se desea hallar todos los documentos que tienen 
las palabras «base de datos» entre sus palabras clave se 
puede utilizar la consulta siguiente: 

select título 

from libros 

where «base de datos» in (unnest (lista-palabras- 
clave')') 

Obsérvese que se ha usado unnest (lista-palabras-cla¬ 
ve) en una posición en la que SQL sin relaciones ani¬ 
dadas habría exigido una subexpresión select-from- 
where. 

Si se sabe que un libro en particular tiene tres auto¬ 
res, se podría escribir: 

select array-autores[ 1], array-autores f2] , 
array-autores[ 3] 

from libros 

where título = ‘Lundamentos de bases de datos’ 

Ahora supóngase que se desea una relación que con¬ 
tenga parejas de la forma «título, nombre-autor» para 
cada libro y para cada uno de los autores del mismo. Se 
puede utilizar la consulta siguiente: 

select B.título, A 

from libros as B, unnest (B .array-autores) as A 
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Dado que el atributo array-autores de libros es un 
campo de tipo colección, puede utilizarse en una ins¬ 
trucción from en la que se espere una relación. 

9.5.3. Atildamiento y desanidamiento 

La transformación de una relación anidada en una for¬ 
ma con menos (o sin) atributos de tipo relación se deno¬ 
mina desanidamiento. La relación libros tiene dos atri¬ 
butos, array-autores y lista-palabras-clave, que son 
colecciones, y otros dos, título y editorial, que no lo 
son. Supóngase que se desea convertir la relación en 
una sola relación plana, sin relaciones anidadas ni tipos 
estructurados como atributos. Se puede utilizar la 
siguiente consulta para llevar a cabo la tarea: 

select título, A as autor, editorial.nombre 
as nombre-edit, editorial.sucursal 
as sucursal.edit, 

K as palabra-clave 

from libros as B, unnest(B.array-autores) 

as A, unnest (B.lista-palabras-clave) as K 

La variable B de la cláusula from se declara para que 
tome valores de libros. La variable A se declara para 
que tome valores de los autores en array-autores para 
el documento B y K se declara para que tome valores 
de las palabras clave de la lista-palabras-clave del mis¬ 
mo. En la Figura 9.1 (del Apartado 9.1) se muestra un 
ejemplo de relación libros y la Figura 9.2 muestra la 
relación 1FN resultado de la consulta anterior. 

El proceso inverso de transformar una relación 1FN 
en una relación anidada se denomina anidamiento. 
El anidamiento puede realizarse mediante una exten¬ 
sión de la agrupación en SQL. En el uso normal de la 
agrupación en SQL se crea (lógicamente) una relación 
multiconjunto temporal para cada grupo y se aplica 
una función de agregación a esa relación temporal. 
Devolviendo el multiconjunto en lugar de aplicar la 
función de agregación se puede crear una relación 
anidada. Supóngase que se tiene la relación 1FN 
libros-planos, tal y como se muestra en la Figura 9.2. 
La consulta siguiente anida la relación en el atributo 
palabra-clave'. 

select título, autor, Editorial(nombre-edit, sucursal-edit) 
as editoricd, setipalabra-cIa ve) 
as lista-palabras-clave 


from libros-planos 
groupby título, autor, editorial 

El resultado de la consulta a la relación libros de la Figu¬ 
ra 9.2 se muestra en la Figura 9.4. Si se desea anidar 
también el atributo autor y volver a convertir, por tan¬ 
to, la tabla libros-planos, en 1FN, en la tabla anidada 
libros mostrada en la Figura 9.1 se puede utilizar la con¬ 
sulta siguiente: 

select título, set (autor) as array-autores, Editorial 
(nombre-eclit, sucursal-edit) as editorial, 
set (palabra-clave) as lista-palabras-clave 
from libros-planos 
groupby título, editorial 

Otro enfoque para la creación de relaciones anida¬ 
das es usar subconsultas en la cláusula select. La siguien¬ 
te consulta, que ilustra este enfoque, realiza la misma 
tarea que la consulta anterior. 

select título, 

(select autor 
from libros-planos as M 
where M.título = O.título) as lista-autores, 
Editorial(nombre-edit, sucursal-edit) as editorial, 
(select palabra-clave 
from libros-planos as N 

where N.título = O.título) as lista-palabras-clave, 
from libros-planos as O 

El sistema ejecuta las subconsultas anidadas de la cláu¬ 
sula select para cada tupia generada por las cláusulas 
from y where de la consulta externa. Obsérvese que el 
atributo O.título de la consulta extema se usa en las con¬ 
sultas anidadas para asegurar que sólo se generan los 
conjuntos correctos de autores y palabras clave para 
cada título. Una ventaja de este enfoque es que se pue¬ 
de usar una cláusula order by en la consulta anidada 
para generar los resultados en el orden deseado. Sin 
dicho orden, los arrays y las listas no estarían unívo¬ 
camente determinados. 

Mientras que el desanidamiento de los atributos de 
tipo array se puede llevar a cabo en SQL: 1999 como 
se ha mostrado, el proceso inverso de anidamiento no 
se soporta en SQL: 1999. Las extensiones que se han 
mostrado para el anidamiento ilustran las característi¬ 
cas de algunas propuestas para la extensión de SQL, 
pero actualmente no forman parte de la norma. 


título 

autor 

editorial 

( nombre-edit, sucursal-edit) 

lista-palabras-clave 

Compiladores 

Gómez 

(McGraw-Hill, Nueva York) 

{traducción, análisis} 

Compiladores 

Santos 

(McGraw-Hill, Nueva York) 

{traducción, análisis} 

Redes 

Santos 

(Oxford, Londres) 

{Internet, Web} 

Redes 

Escudero 

(Oxford, Londres) 

{Internet, Web} 


FIGURA 9.4. Una versión parcialmente anidada de la relación libros-planos. 
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9.6. FUNCIONES Y PROCEDIMIENTOS 


SQL: 1999 permite la definición de funciones, procedi¬ 
mientos y métodos. Se pueden definir mediante el com¬ 
ponente procedimental de SQL: 1999 o mediante un len¬ 
guaje de programación como Java, C o C++. En primer 
lugar se examinarán las definiciones en SQL: 1999 y 
después se verá cómo usar las definiciones en lengua¬ 
jes externos. Algunos sistemas de bases de datos sopor¬ 
tan sus propios lenguajes procedimentales, tales como 
PL/SQL en Oracle y TransactSQL en SQL Server de 
Microsoft. Éstos incorporan una parte procedimental 
parecida a SQL: 1999, pero hay diferencias en la sinta¬ 
xis y la semántica; véanse los manuales de sistema res¬ 
pectivos para más detalles. 

9.6.1. Funciones y procedimientos en SQL 

Supóngase que se desea una función que, dado un libro, 
devuelva el recuento del número de autores usando el 
esquema 4FN. Se puede definir la función de la mane¬ 
ra siguiente: 

create function recuento-autores (título varchar(20)) 

returns integer 
begin 

declare recuento-a integer; 

select count (autor) into recuento-a 
from autores 

where autores.título = título 
return recuento-a', 

end 

La función anterior se puede utilizar en una consul¬ 
ta que devuelva los títulos de todos los libros que ten¬ 
gan más de un autor: 

select título 
from libros4 

where recuento-autores(título) > 1 

Las funciones son particularmente útiles con tipos 
de datos especializados tales como las imágenes y los 
objetos geométricos. Por ejemplo, un tipo de datos polí¬ 
gono usado en una base de datos cartográfica puede 
tener asociada una función que compruebe si solapan 
dos polígonos, y un tipo de datos imagen puede tener 
asociadas funciones para comparar la semejanza de dos 
imágenes. Las funciones se pueden escribir en un len¬ 
guaje externo como C, como se vio en el Apartado 9.6.2. 
Algunos sistemas de bases de datos también soportan 
funciones que devuelven relaciones, es decir, multi- 
conjuntos de tupias, aunque tales funciones no se sopor¬ 
tan en SQL: 1999. 

Los métodos, que se vieron en el Apartado 9.2.2, se 
pueden ver como funciones asociadas a tipos estructu¬ 
rados. Tienen un primer parámetro implícito denomina¬ 


do self, que se establece al valor del tipo estructurado 
sobre el que se invoca el método. Así, el cuerpo del méto¬ 
do puede referirse a un atributo a del valor usando self.a. 
El método también puede actualizar estos atributos. 

SQL: 1999 también soporta procedimientos. La fun¬ 
ción recuento-autores se podría haber escrito como un 
procedimiento: 

create procedure proc-recuento-autores 
(in título varchar(20), out recuento-a integer) 
begin 

select count (autor) into recuento-a 
from autores 

where autores.título = título 

end 

Los procedimientos se pueden invocar desde un pro¬ 
cedimiento SQL o desde SQL incorporado con la ins¬ 
trucción cali: 

declare recuento-a integer; 

cali proc-recuento-autores( ‘Fundamentos de bases 

de datos’, recuento-a)', 

SQL: 1999 permite que más de un procedimiento ten¬ 
ga el mismo nombre mientras que el número de los argu¬ 
mentos de estos procedimientos sea diferente. El nom¬ 
bre, junto con el número de argumentos, se usa para 
identificar el procedimiento. SQL: 1999 también per¬ 
mite que más de una función tenga el mismo nombre, 
siempre que las funciones con el mismo nombre tengan 
un número diferente de argumentos o que las que ten¬ 
gan el mismo número difieran al menos en el tipo de un 
argumento. 

9.6.2. Rutinas externas del lenguaje 

SQL: 1999 permite definir funciones en un lenguaje de 
programación tal como C o C++. Las funciones defini¬ 
das así pueden ser más eficientes que las definidas en 
SQL, y los cálculos que no se pueden realizar en SQL 
se pueden ejecutar por estas funciones. Un ejemplo de 
tales funciones sería realizar un cálculo aritmético com¬ 
plejo sobre los datos de una tupia. 

Los procedimientos y funciones externos se pueden 
especificar de la siguiente forma: 

create procedure proc-recuento-autores (in título 
varchar(20), out recuento-a integer) 
language C 

external ñame ‘/usr/avi/bin/proc-recuento-autores’ 

create function recuento-autores (título varchar(20)) 
returns integer 
language C 

external ñame ‘/usr/avi/bin/recuento-autores’ 
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Los procedimientos externos del lenguaje necesitan 
manejar valores nulos y excepciones. Deben tener por 
tanto varios parámetros extra: un valor sqlstate para 
indicar el estado de fallo o éxito, un parámetro para 
almacenar el valor devuelto por la función, y variables 
indicadoras para cada parámetro y resultado de la fun¬ 
ción para indicar si el valor es nulo. La línea extra para¬ 
meter style general añadida a la declaración anterior 
indica que las funciones o procedimientos externos sólo 
pueden tomar los argumentos mostrados y no manejan 
valores nulos o excepciones. 

Las funciones definidas en un lenguaje de progra¬ 
mación y compiladas fuera del sistema de bases de datos 
se pueden cargar y ejecutar con el código del sistema 
de bases de datos. Sin embargo, al hacerlo así se cae en 
el riesgo de que un error en el programa pueda corrom¬ 
per las estructuras internas de la base de datos, y puede 
omitir la funcionalidad de control de acceso del siste¬ 
ma de bases de datos. Los sistemas de bases de datos 
que están más preocupados por el rendimiento que por 
la seguridad pueden ejecutar procedimientos de esta for¬ 
ma. 

Los sistemas de bases de datos que están preocupa¬ 
dos por la seguridad ejecutarían normalmente este códi¬ 
go como parte de un proceso separado, le comunicarían 
los valores de los parámetros y extraerían los resulta¬ 
dos mediante comunicación entre procesos. 

Si el código se escribe en un lenguaje como Java, 
hay una tercera posibilidad: la ejecución del código en 
un «cubo» dentro del mismo proceso de la base de 
datos. El cubo evita que el código Java realice cual¬ 
quier lectura o escritura directamente en la base de 
datos. 

9.6.3. Constructoras procedimentales 

SQL: 1999 soporta varias constructoras procedimenta¬ 
les que proporcionan casi toda la potencia de un len¬ 
guaje de programación de propósito general. La parte 
de la norma SQL: 1999 que maneja estas constructoras 
se denomina Módulo de almacenamiento persisten¬ 
te (Persistent Storage Module, PSM). 

Una instrucción compuesta es de la forma begin ... 
end, y puede contener varias instrucciones SQL entre 
begin y end. Se pueden declarar variables locales den¬ 
tro de una instrucción compuesta, como se ha visto en 
el Apartado 9.6.1. 

SQL: 1999 soporta instrucciones while y repeat con 
esta sintaxis: 

declare n integer default 0; 
while n < 10 do 
set n - n +1; 
end while 
repeat 

set n = n- 1; 
until n = 0 
end repeat 


Este código no hace nada útil; simplemente está para 
mostrar la sintaxis de los bucles while y repeat. Se verán 
usos con más sentido posteriormente. 

También hay un bucle for, que permite la iteración 
sobre los resultados de una consulta. 

declare n integer default 0; 

for r as 

select saldo from cuenta 

where nombre-sucursal = ‘Navacerrada’ 

do 

set n = n + r.saldo', 

end for 

El programa abre implícitamente un cursor cuando el 
bucle for inicia la ejecución y lo usa para extraer los 
valores por filas en la variable del bucle for (r en el 
ejemplo). Es posible dar un nombre al cursor insertan¬ 
do el texto nc cursor for justo después de la palabra 
clave as, donde nc es el nombre que se desea dar al cur¬ 
sor. El nombre del cursor se puede usar para realizar 
operaciones de actualización o borrado sobre la tupia 
apuntada por el cursor. La instrucción leave se puede 
usar para abandonar el bucle, mientras que itérate 
comienza en la siguiente tupia, desde el principio del 
bucle, saltando el resto de instrucciones. 

El resto de instrucciones soportadas por SQL: 1999 
incluye instrucciones if-then-else con esta sintaxis: 

if r.saldo < 1000 

then set p = p + r.saldo 
elseif r.saldo < 5000 

then set m = m + r.saldo 
else set g = g + r.saldo 
end if 

Este código asume que /, m y h son variables enteras y 
que r es una variable de filas. Si se reemplaza la línea «set 
n = n + r.saldo » en el bucle for del párrafo anterior por 
código if-then-else, el bucle calculará los saldos totales 
de las cuentas que se encuentran por debajo de las cate¬ 
gorías de saldo pequeño, medio y grande, respectivamente. 

SQL: 1999 también da soporte a una instrucción case 
similar a la del lenguaje C/C++ (además de las expre¬ 
siones case que se vieron en el Capítulo 4). 

Finalmente, SQL: 1999 incluye el concepto de la emi¬ 
sión de condiciones de excepción, y la declaración de 
controladores que pueden manejar la excepción, como 
en el código: 

declare sin-existencias condition 
declare exit handler for sin-existencias 
begin 

end 

Las instrucciones entre begin y end pueden emitir una 
excepción ejecutando signal sin-existencias. El contro¬ 
lador dice que si surge la condición, la acción a empren¬ 
der es salir de la instrucción de grupo begin ... end. Las 
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acciones alternativas serían continué, que continúa la 
ejecución desde la siguiente instrucción a la que emitió 
la excepción. Además de condiciones definidas explí¬ 
citamente, también hay condiciones predefinidas tales 
como sqlexception, sqlwarning y not found. 

La Figura 9.5 proporciona un ejemplo mayor del uso 
de las constructoras procedimentales de SQL: 1999. El 
procedimiento hallarEmpl calcula el conjunto de todos 
los empleados directos e indirectos de un jefe dado 
(especificado por el parámetro jef) y almacena los nom¬ 
bres de empleados resultantes en una relación llamada 
empl, que se asume que ya está disponible. El conjun¬ 
to de todos los empleados directos e indirectos es bási¬ 
camente el cierre transitivo de la relación jefe. Se vio 
cómo expresar tal consulta mediante recursión en el 
Capítulo 5 (Apartado 5.2.6). 

El procedimiento usa dos tablas temporales, nuevo- 
emp y temp. El procedimiento inserta todos los emplea¬ 
dos que trabajan directamente para jef antes del bucle 
repeat. Este bucle añade en primer lugar todos los 
empleados de nuevoemp a empl. A continuación deter¬ 
mina los empleados que trabajan para los de nuevoemp, 
excepto los que ya se hayan determinado que son 


empleados de jef y los almacena en la tabla temporal 
temp. Finalmente, reemplaza los contenidos de nuevo¬ 
emp por los contenidos de temp. El bucle repeat ter¬ 
mina cuando no se encuentran nuevos empleados (indi¬ 
rectos). 

El uso de la cláusula except en el procedimiento ase¬ 
gura que éste funciona incluso en el caso (anormal) de 
que haya un ciclo en los jefes. Por ejemplo, si a traba¬ 
ja para b, b trabaja para c y c trabaja para a, hay un ciclo. 

Mientras que los ciclos no son realistas en el caso 
real de los jefes, son posibles en otras aplicaciones. 
Por ejemplo, supóngase que se tiene una relación vue- 
lo(a, desde) que especifica las ciudades a las que se 
puede llegar con un vuelo directo. Se puede modificar 
el procedimiento HallarEmpl para determinar todas 
las ciudades que se pueden alcanzar mediante una 
secuencia de uno o más vuelos desde una ciudad deter¬ 
minada. Todo lo que hay que hacer es reemplazar jefe 
por vuelo y reemplazar los nombres de atributo ade¬ 
cuadamente. En esta situación puede haber ciclo por 
alcanzabilidad, pero el procedimiento funcionaría 
correctamente, dado que eliminaría las ciudades que 
ya se han visitado. 


create procedure hallarEmpl (in yefchar(IO)) 

— Halla todos los empleados que trabajan directa o indirectamente para jef 
— y los añade a la relación empl(nombre). 

— La relación jefe(nombreemp, nombrejef) especifica quién trabaja 
-- para quién. 

begin 

create temporary table nuevoemp (nombre char(10)); 
create temporary table temp (nombre char(IOj); 
insert into nuevoemp 
select nombreemp 
from jefe 

where nombrejef = jef 

repeat 

insert into empl 
select nombre 
from nuevoemp; 

insert into temp 

(select jefe.nombreemp 
from nuevoemp, jefe 

where nuevoemp.nombreemp = jefe.nombrejef: 

) 

except( 

select nombreemp 
from empl 

); 

delete from nuevoemp; 
insert into nuevoemp 
select * 
from temp; 
delete from temp; 

until not exists (select * from nuevoemp) 
end repeat; 

end 

FIGURA 9.5. Determinación de todos los empleados de un jefe. 
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9.7. COMPARACIÓN ENTRE LAS BASES DE DATOS ORIENTADAS A OBJETOS 
Y LAS BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS 


Ya se han estudiado las bases de datos orientadas a obje¬ 
tos creadas alrededor de los lenguajes de programación 
persistentes y las bases de datos relaciónales orientadas 
a objetos, que son bases de datos orientadas a objetos 
construidas sobre el modelo relacional. Ambos tipos de 
sistemas de bases de datos se hallan en el mercado y los 
diseñadores de bases de datos deben escoger el tipo de 
sistema que resulte más adecuado para las necesidades 
de cada aplicación. 

Las extensiones persistentes de los lenguajes de pro¬ 
gramación y los sistemas relaciónales orientados a obje¬ 
tos se han dirigido a mercados diferentes. La naturale¬ 
za declarativa y la limitada potencia (comparada con la 
de los lenguajes de programación) del lenguaje SQL 
proporcionan una buena protección de los datos res¬ 
pecto de los errores de programación y hace que las 
optimizaciones de alto nivel, como la reducción de E/S, 
resulten relativamente sencillas. (La optimización de 
las expresiones relaciónales se trata en el Capítulo 13). 
Los sistemas relaciónales orientados a objetos se diri¬ 
gen a la simplificación de la realización de los modelos 
de datos y de las consultas mediante el uso de tipos de 
datos complejos. Las aplicaciones típicas incluyen el 
almacenamiento y la consulta de datos complejos, inclu¬ 
yendo los datos multimedia. 

Los lenguajes declarativos como SQL, sin embar¬ 
go, imponen una reducción significativa del rendimiento 
a ciertos tipos de aplicaciones que se ejecutan princi¬ 
palmente en la memoria principal y realizan gran núme¬ 
ro de accesos a la base de datos. Los lenguajes de pro¬ 
gramación persistentes se dirigen a las aplicaciones de 
este tipo que tienen necesidad de elevados rendimien¬ 
tos. Proporcionan acceso a los datos persistentes con 
poca sobrecarga y eliminan la necesidad de la traduc¬ 
ción de los datos si hay que tratarlos utilizando un len¬ 
guaje de programación. Sin embargo, son más suscep¬ 
tibles de deteriorar los datos debido a los errores de 
programación y no suelen disponer de grandes posibi¬ 
lidades de consulta. Las aplicaciones típicas incluyen 
las bases de datos de CAD. 

Los puntos fuertes de los varios tipos de sistemas de 
bases de datos pueden resumirse de la manera siguiente: 


• Sistemas relaciónales: tipos de datos sencillos, 
lenguajes de consulta potentes, protección elevada. 

• Bases de datos orientadas a objetos basadas en 
lenguajes de programación persistentes: tipos 
de datos complejos, integración con los lenguajes 
de programación, elevado rendimiento. 

• Sistemas relaciónales orientados a objetos: tipos 
de datos complejos, lenguajes de consulta poten¬ 
tes, protección elevada. 

Estas descripciones son válidas en general, pero hay que 
tener en cuenta que algunos sistemas de bases de datos 
no respetan estas fronteras. Por ejemplo, algunos siste¬ 
mas de bases de datos orientados a objetos construidos 
alrededor de lenguajes de programación persistentes se 
implementan sobre sistemas de bases de datos relació¬ 
nales. Puede que estos sistemas proporcionen menor 
rendimiento que los sistemas de bases de datos orien¬ 
tados a objetos construidos directamente sobre los sis¬ 
temas de almacenamiento, pero proporcionan en parte 
las garantías de protección más estrictas propias de los 
sistemas relaciónales. 

Muchos sistemas de bases de datos relaciónales 
orientados a objetos se construyen sobre bases de datos 
relaciónales existentes. Para ello, los tipos de datos com¬ 
plejos soportados por los sistemas relaciónales orienta¬ 
dos a objetos necesitan traducirse al sistema de tipos 
más sencillo de las bases de datos relaciónales. 

Para comprender cómo se realiza la traducción sólo 
es necesario examinar la forma en que algunas caracte¬ 
rísticas del modelo E-R se traducen en relaciones. Por 
ejemplo, los atributos multivalorados del modelo E-R 
se corresponden con los atributos de tipo conjunto del 
modelo relacional orientado a objetos. Los atributos 
compuestos se corresponden grosso modo con los tipos 
estructurados. Las jerarquías ES del modelo E-R se 
corresponden con la herencia de tablas en el modelo 
relacional orientado a objetos. Las técnicas para con¬ 
vertir las características del modelo E-R a tablas, que 
se vieron en el Apartado 2.9, se pueden usar con algu¬ 
nas extensiones para traducir los datos relaciónales 
orientados a objetos en datos relaciónales. 


9.8. RESUMEN 


El modelo de datos relacional orientado a objetos ex¬ 
tiende el modelo de datos relacional proporcionando 
un sistema de tipos enriquecido que incluye tipos 
colección y orientación a objetos. 

La orientación a objetos proporciona herencia con sub¬ 
tipos y subtablas, así como referencias a objetos (tupias). 


• Los tipos colección incluyen relaciones anidadas, con¬ 
juntos, multiconjuntos y arrays, y el modelo relacio¬ 
nal orientado a objetos permite que los atributos de 
las tablas sean colecciones. 

• La norma SQL: 1999 extiende el lenguaje de defini¬ 
ción de datos, así como el lenguaje de consultas, y 
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en particular da soporte a atributos de tipo colec¬ 
ción, herencia y referencias a tupias. Estas exten¬ 
siones intentan preservar los fundamentos rela¬ 
ciónales —en particular, el acceso declarativo a los 
datos— a la vez que se extiende la potencia de mode¬ 
lado. 

• Los sistemas relaciónales orientados a objetos (es 
decir, sistemas de bases de datos basados en el mode¬ 
lo relacional orientado a objetos) proporcionan un 


camino de migración adecuado para los usuarios de 
las bases de datos relaciónales que desean usar las 
características de la orientación a objetos. 

• También se han descrito extensiones procedimenta- 
les proporcionadas por SQL: 1999. 

• Se han discutido las diferencias entre los lenguajes de 
programación persistente y los sistemas relaciónales 
orientados a objetos, y se han mencionado criterios 
para escoger entre ellos. 


TÉRMINOS DE REPASO 


• Alcance de una referencia. 

• Anidamiento y desanidamiento. 

• Arrays. 

• Atributo autorreferencial. 

• Conjuntos. 

• Constructoras. 

• Constructoras procedimentales. 

• Controladores. 

• Excepciones. 

• Expresiones de ruta. 

• Funciones y procedimientos en SQL. 

• Herencia. 

— Herencia múltiple. 

— Herencia simple. 

• Herencia de tablas. 

• Herencia de tipos. 


• Métodos. 

• Modelo relacional anidado. 

• Multiconjuntos. 

• Objetos grandes de caracteres (clob). 

• Objetos grandes en binario (blob). 

• Relaciones anidadas. 

• Rutinas externas del lenguaje. 

• Solapamiento de subtablas. 

• Subtabla. 

• Tipo más específico. 

• Tipos colección. 

• Tipos complejos. 

• Tipos estructurados. 

• Tipos fila. 

• Tipos de objetos grandes. 

• Tipos referencia. 


EJERCICIOS 


9.1. Considérese el esquema de la base de datos 

Emp = ( nombree, setof (Hijos), seto {(Conocimientos)) 
Hijos = ( nombre, Cumpleaños) 

Cumpleaños = {día, mes, año) 

Conocimientos = {escribir-a-máquina, setof{Exámenes)) 
Exámenes = {año, ciudad) 

Asúmase que los atributos de tipo setof{Hijos), 
setof {Conocimientos) y setof (Exámenes) tienen nom¬ 
bres de atributo ConjuntoHijos, ConjuntoConoci- 
mientos y Conjunto Exámenes, respectivamente. Supón¬ 
gase que la base de datos contiene una relación 
emp{Emp). Escríbanse en SQL: 1999 las consultas 
siguientes (con las extensiones descritas en este capí¬ 
tulo). 

a. Hallar los nombres de todos los empleados que ten¬ 
gan hijos nacidos en marzo. 


b. Hallar los empleados que hicieron un examen del 
tipo de conocimiento «escribir-a-máquina» en la ciu¬ 
dad «San Rafael». 

c. Indicar todos los tipos de conocimiento de la rela¬ 
ción emp. 

9.2. Vuélvase a diseñar la base de datos del Ejercicio 9.1 
en la primera forma normal y en la cuarta forma nor¬ 
mal. Indíquense las dependencias funcionales o multi- 
valoradas que se den por supuestas. Indíquense tam¬ 
bién todas las restricciones de integridad referencial 
que deban incluirse en los esquemas de la primera y de 
la cuarta formas normales. 

9.3. Considérense los esquemas de la tabla persona y las 
tablas estudiantes y profesores que se crearon bajo per¬ 
sona en el Apartado 9.3. Dese un esquema relacional 
en la tercera forma normal que represente la misma 
información. Recuérdense las restricciones de las sub- 
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tablas y dense todas las restricciones que deban impo¬ 
nerse en el esquema relacional para que cada ejemplar 
de la base de datos del esquema relacional pueda repre¬ 
sentarse también mediante un ejemplar del esquema 
con herencia. 

9.4. Una compañía de alquiler de coches tiene una base 
de datos de vehículos con todos los vehículos de su 
flota actual. Para todos los vehículos incluye su núme¬ 
ro de bastidor, su número de matrícula, el fabricante, 
el modelo, la fecha de adquisición y su color. Se inclu¬ 
yen datos específicos para algunos tipos de vehícu¬ 
los: 

• Camiones: capacidad de carga. 

• Coches deportivos: potencia, edad mínima del arren¬ 
datario. 

• Monovolúmenes: número de plazas. 

• Vehículos todoterreno: altura de los bajos, eje motor 
(tracción a dos ruedas o a las cuatro). 

Constrúyase una definición de esquema para esta base 
de datos en SQL: 1999. Utilícese la herencia donde 
resulte conveniente. 

9.5. Expliqúese la diferencia entre un tipo x y un tipo refe¬ 
rencia ref(.v). ¿En qué circunstancias se debe escoger 
un tipo referencia? 

9.6. Considérese el diagrama E-R de la Figura 2.11, que 
contiene atributos compuestos, multivalorados y deri¬ 
vados. 

a. Dese una definición de esquema en SQL: 1999 
correspondiente al diagrama E-R. Utilícese un array 
para representar el atributo multivalorado y cons¬ 
tructoras apropiadas de SQL: 1999 para representar 
los otros tipos de atributos. 

b. Dense constructores para cada uno de los tipos 
estructurados definidos. 

9.7. Dese una definición de esquema en SQL: 1999 del dia¬ 
grama E-R de la Figura 2.17, que contiene especiali- 
zaciones. 

9.8. Considérese el esquema relacional de la Figura 3.39. 


a. Dese una definición de esquema en SQL: 1999 
correspondiente al esquema relacional, pero usan¬ 
do referencias para expresar las relaciones de cla¬ 
ves externas. 

b. Escríbanse cada una de las consultas del Ejercicio 
3.10 en el esquema anterior usando SQL: 1999. 

9.9. Considérese una base de datos de empleados con las 
relaciones 

emvleado( nombre-emvleado . calle , ciudad) 
trabaial nombre-empleado , nombre-empresa, sueldo ) 

donde las claves primarias se han subrayado. Escríba¬ 
se una consulta para hallar las empresas cuyos emple¬ 
ados ganan un sueldo mayor, de media, que el sueldo 
medio del Banco Importante. 

a. Usando funciones SQL: 1999 donde sea apropiado. 

b. Sin usar funciones SQL: 1999. 

9.10. Reescríbase la consulta del Apartado 9.6.1 que devuel¬ 
ve los títulos de todos los libros que tengan más de un 
autor usando la cláusula with en lugar de la función. 

9.11. Compárese el uso de SQL incorporado con el uso en 
SQL de las funciones definidas utilizando un lenguaje 
de programación de propósito general ¿En qué circuns¬ 
tancias se debe utilizar cada una de estas características? 

9.12. Supóngase que se ha sido contratado como asesor para 
escoger un sistema de bases de datos para la aplicación 
del cliente. Para cada una de las aplicaciones siguien¬ 
tes indíquese el tipo de sistema de bases de datos (rela¬ 
cional, base de datos orientada a objetos basada en un 
lenguaje de programación persistente, relacional orien¬ 
tada a objetos; no se debe especificar ningún producto 
comercial) que se recomendaría. Justifiqúese la reco¬ 
mendación. 

a. Sistema de diseño asistido por computadora para un 
fabricante de aviones. 

b. Sistema para realizar el seguimiento de los donati¬ 
vos hechos a los candidatos a un cargo público. 

c. Sistema de información de ayuda para la realización 
de películas. 


NOTAS BIBLIOGRÁFICAS 


El modelo relacional anidado lo introdujeron Maki- 
nouchi [1977] y Jaeschke y Schek [1982]. En Fischer y 
Thomas [1983], Zaniolo [1983], Ozsoyoglu et al. [1987], 
Gucht [1987] y Roth et al. [1988] se presentan varios 
lenguajes algebraicos de consulta. La gestión de los 
valores nulos en las relaciones anidadas se discute en 
Roth et al. [1989]. Los problemas de diseño y de nor¬ 
malización se discuten en Ozsoyoglu y Yuan [1987], 
Roth y Korth [1987] y Mok et al. [1996]. En Abiteboul 
et al. [1989] aparece una colección de trabajos sobre las 
relaciones anidadas. 

Se han propuesto varias extensiones de SQL orien¬ 
tadas a objetos. POSTGRES (Stonebraker y Rowe 


[1986] y Stonebraker [1986a, 1987]) fue una de las pri¬ 
meras implementaciones de un sistema relacional orien¬ 
tado a objetos. Illustra es el sistema relacional orienta¬ 
do a objetos comercial sucesor de POSTGRES (Informix 
compró posteriormente Illustra, que a su vez fue com¬ 
prado por IBM). El sistema de bases de datos Iris de 
Hewlett-Packard (Fishman et al. [1990] y Wilkinson et 
al. [1990]) proporciona extensiones orientadas a obje¬ 
tos sobre un sistema de bases de datos relacional. El len¬ 
guaje de consulta 0 2 descrito en Bancilhon et al. [1989] 
es una extensión de SQL orientada a objetos imple- 
mentada en el sistema de bases de datos orientado a 
objetos 0 2 (Deux [1991]). UniSQL se describe en 
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UniSQL [1991]. XSQL es una extensión de SQL orien¬ 
tada a objetos propuesta por Kifer et al. [1992]. 

SQL: 1999 fue el producto de un esfuerzo extensivo 
(y retrasado) de normalización, que se inició original¬ 
mente añadiendo características de la programación 
orientada a objetos a SQL, y finalizó añadiéndose 
muchas otras características, como el flujo de control. 


como se ha visto. Los documentos de la norma están 
disponible (mediante pago) en http://webstore.ansi.org. 
Sin embargo, los documentos de la norma son difíciles 
de leer y se dejan a los implementadores de SQL: 1999. 
Hay libros en edición sobre SQL: 1999 en el momento 
de la escritura de este libro; véase el sitio Web del libro 
para información actual. 


HERRAMIENTAS 


El sistema de bases de datos Informix proporciona 
soporte para muchas características relaciónales orien¬ 
tadas a objetos. Oracle introdujo varias características 
relaciónales orientadas a objetos en Oracle 8.0. Ambos 
sistemas proporcionaron características relaciónales 


orientadas a objetos antes de que la norma SQL: 1999 
estuviese finalizada, y tienen algunas características 
que no forman parte de la norma SQL: 1999. DB2 de 
IBM soporta muchas de las características de 
SQL: 1999. 
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A diferencia de la mayor parte de las tecnologías presentadas en los capítulos anteriores, 
el lenguaje de marcas extensible (Extensible Markup Language, XML ) no se con¬ 
cibió como una tecnología para bases de datos. En realidad, al igual que el lenguaje 
ele marcas de hipertexto ( Hyper-Text Markup Language, HTML) sobre el que está basado 
World Wide Web, XML; tiene sus raíces en la gestión de documentos y está derivado de un 
lenguaje para estructurar documentos grandes conocido como lenguaje estándar generaliza¬ 
do de marcas (Standard Generalized Markup Language, SGML). Sin embargo, a diferencia 
de SGML y HTML, XML puede representar datos de bases de datos, así como muchas clases 
de datos estructurados usadas en aplicaciones de negocios. Es particularmente útil como for¬ 
mato de datos cuando las aplicaciones se deben comunicar con otra aplicación o integrar infor¬ 
mación de varias aplicaciones. Cuando XML se usa en estos contextos, se generan muchas 
dudas sobre las bases de datos, incluyendo cómo organizar, manipular y consultar los datos 
XML. En este capítulo se realiza una introducción sobre XML y se discute la gestión de los 
datos XML con las técnicas de bases de datos, así como el intercambio de datos con formato 
como documentos XML. 


10.1. ANTECEDENTES 


Para comprender XML es importante entender sus raí¬ 
ces como un lenguaje de marcas de documentos. El tér¬ 
mino marca se refiere a cualquier elemento en un docu¬ 
mento del que no se tiene intención que sea parte de la 
salida impresa. Por ejemplo, un escritor que crea un tex¬ 
to que finalmente se compone en una revista puede dese¬ 
ar realizar notas sobre cómo se ha de realizar la com¬ 
posición. Sería importante introducir estas notas de 
forma que se pudieran distinguir del contenido real, de 
forma que una nota como «no romper esta párrafo» no 
acabe impresa en la revista. En un procesamiento elec¬ 
trónico de documentos un lenguaje de marcas es una 
descripción formal de qué parte del documento es con¬ 
tenido, qué parte es marca y lo que significa la marca. 

Así como los sistemas de bases de datos evolucio¬ 
naron desde el procesamiento físico de archivos para 
proporcionar una vista lógica aislada, los lenguajes de 
marcas evolucionaron desde la especificación de ins¬ 
trucciones que indicaban cómo imprimir partes del docu¬ 
mento para la función del contenido. Por ejemplo, con 
marcas funcionales, el texto que representa los encabe¬ 
zamientos de sección (para esta sección la palabra 
«Antecedentes») se marcaría como un encabezamien¬ 
to de sección en lugar de marcarse como un texto con 
el fin de ser impreso en un tamaño agrande, con fuente 
en negrita. Dicha marca funcional permite que el docu¬ 
mento tenga distintos formatos en situaciones diferen¬ 
tes. También ayuda a que distintas partes de un docu¬ 


mento largo, o distintas páginas en un sitio Web gran¬ 
de, tengan un formato uniforme. La marca funciona tam¬ 
bién ayuda a la extracción automática de partes claves 
de los documentos. 

Para la familia de lenguajes de marcado, en los que 
se incluye HTML, SGML y XML las marcas adoptan 
la forma de etiquetas encerradas entre corchetes angu¬ 
lares , < >. Las etiquetas se usan en pares, con <etique- 
ta> y </etiqueta> delimitando el comienzo y final de la 
porción de documento a la cual se refiere la etiqueta. 
Por ejemplo, el título de un documento podría estar mar¬ 
cado de la siguiente forma: 

<title>Fundamentos de bases de datos</title> 

A diferencia de HTML, XML no prescribe las eti¬ 
quetas permitidas, y se pueden establecer etiquetas según 
cada necesidad. Esta característica es la clave de la fun¬ 
ción principal de XML en la representación e inter¬ 
cambio de datos, mientras que HTML se usa principal¬ 
mente para el formato de documentos. 

Por ejemplo, en nuestra aplicación del banco, la infor¬ 
mación de la cuenta y del cliente se puede representar 
como parte de un documento XML, como se muestra 
en la Ligura 10.1. Obsérvese el uso de etiquetas tales 
como cuenta y número-cuenta. Estas etiquetas propor¬ 
cionan el contexto de cada valor y permiten identificar 
la semántica del valor. 
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</banco> 

<cuenta> 

<número-cuenta> C-101 </número-cuenta> 
<nombre-sucursal> Centro </nombre-sucursal> 
<saldo> 500 </saldo> 

</cuenta> 

<cuenta> 

<número-cuenta> C-102 </número-cuenta> 
<nombre-sucursal> Navacerrada </nombre-sucursal> 
<saldo> 400 </saldo> 

</cuenta> 

<cuenta> 

<número-cuenta> C-201 </número-cuenta> 
<nombre-sucursal> Galapagar </nombre-sucursal> 
<saldo> 900 </saldo> 

</cuenta> 

<cliente> 

<nombre-cliente> González </nombre-cliente> 
<calle-cliente> Arenal </calle-cliente> 

<ciudad-cliente> La Granja </ciudad-cliente> 

</cliente> 

<cllente> 

<nombre-cliente> López </nombre-cliente> 
<calle-cliente> Mayor </calle-cliente> 

<ciudad-cliente> PeguEtrerosos </ciudad-cliente> 
</cliente> 

<¡mpositor> 

<número-cuenta> C-101 </número-cuenta> 
<nombre-cliente> González </nombre-cliente> 
</¡mpositor> 

<¡mpositor> 

<número-cuenta> C-201 </número-cuenta> 
<nombre-cliente> González </nombre-cliente> 
</¡mpositor> 

<¡mpositor> 

<número-cuenta> C-102 </número-cuenta> 
<nombre-cliente> López </nombre-cliente> 
</¡mpositor> 

</banco> 

FIGURA 10.1. Representación XML de información bancaria. 


Comparado al almacenamiento de los datos en una 
base de datos, la representación XML puede parecer 
poco eficiente, puesto que los nombres de las etiquetas 
se repiten por todo el documento. Sin embargo, a pesar 
de esta desventaja, una representación XML presenta 
ventajas significativas cuando se usa para el intercam¬ 
bio de datos como, por ejemplo, parte de un mensaje. 

• En primer lugar la presencia de las etiquetas hace 
que el mensaje sea autodocumentado, es decir, 
no se tiene que consultar un esquema para com¬ 
prender el significado del texto. Se puede leer fácil¬ 
mente el fragmento anterior, por ejemplo. 

• En segundo lugar, el formato del documento no es 
rígido. Por ejemplo, si algún remitente agrega 
información adicional tal como una etiqueta últi- 
mo-acceso que informa de la última fecha en la 
que se ha accedido a la cuenta, el receptor de los 
datos XML puede sencillamente ignorar la etiqueta. 
La habilidad de reconocer e ignorar las etiquetas 
inesperadas permite al formato de los datos evo¬ 
lucionar con el tiempo sin invalidar las aplicacio¬ 
nes existentes. 

• Finalmente, puesto que el formato XML está 
ampliamente aceptado hay una gran variedad de 
herramientas disponibles para ayudar a su proce¬ 
samiento, incluyendo software de búsqueda y 
herramientas de bases de datos. 

Al igual que SQL es el lenguaje dominante para 
consultar los datos relaciónales XML se está convir¬ 
tiendo en el formato dominante para el intercambio 
de datos. 


10.2. ESTRUCTURA DE LOS DATOS XML 


El constructor fundamental en un documento XML es 
el elemento. Un elemento es sencillamente un par de 
etiquetas de inicio y finalización coincidentes y todo el 
texto que aparece entre ellas. 

Los documentos XML deben tener un único elemento 
raíz que abarque el resto de elementos en el documen¬ 
to. En el ejemplo de la Figura 10.1 el elemento <ban- 
co> forma el elemento raíz. Además, los elementos en 
un documento XML se deben anidar adecuadamente. 
Por ejemplo 

<cuenta> ... <saldo> ... </saldo> ... </cuenta> 
está anidado adecuadamente, mientras que 

<cuenta> ... <saldo> ... </cuenta> ... </saldo> 
no está adecuadamente anidado. 


Aunque el anidamiento adecuado es una propiedad 
intuitiva, la debemos definir más formalmente. Se dice 
que el texto aparece en el contexto de un elemento si 
aparece entre la etiqueta de inicio y la etiqueta de fina¬ 
lización de dicho elemento. Las etiquetas están anida¬ 
das adecuadamente si toda etiqueta de inicio tiene una 
única etiqueta de finalización coincidente que está en el 
contexto del mismo elemento padre. 

Nótese que el texto puede estar mezclado con los 
subelementos de otro elemento, como en la Figura 10.2. 
Como con otras características de XML, esta libertad 
tiene más sentido en un contexto de procesamiento de 
documentos que en el contexto de procesamiento 
de datos y no es particularmente útil para representar 
en XML datos más estructurados como son el conteni¬ 
do de las bases de datos. 

La capacidad de anidar elementos con otros ele¬ 
mentos proporciona una forma alternativa de repre- 
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<cuenta> 

Esta cuenta se usa muy rara vez por no decir nunca. 
<número-cuenta> C-102 </número-cuenta> 
<nombre-sucursal> Navacerrada </nombre-sucursal> 
<saldo> 400 </saldo> 

</cuenta> 


FIGURA 10.2. Mezcla de texto con subelementos. 


sentar información. La Figura 10.3 muestra una repre¬ 
sentación de la información bancaria de la Figura 10.1, 
pero con los elementos cuenta anidados con los ele¬ 
mentos cliente, aunque almacenaría elementos cuenta 
de una forma redundante si pertenecen a varios clien¬ 
tes. 

Las representaciones anidadas se usan ampliamente 
en las aplicaciones de intercambio de datos XML para 
evitar las reuniones. Por ejemplo, una aplicación de 
envíos almacenaría la dirección completa del emisor y 
receptor de una forma redundante en un documento de 
envío asociado con cada envío mientras que una repre¬ 
sentación normalizada puede requerir una reunión de 
registros de envío con una relación compañía-dirección 
para obtener la información de la dirección. 

Además de los elementos, XML especifica la noción 
de atributo. Por ejemplo, el tipo de una cuenta se pue¬ 
de representar como un atributo, como en la Figura 10.4. 
Los atributos de un elemento aparecen como pares nom¬ 
bre = valor antes del cierre « >» de una etiqueta. Los 
atributos son cadenas y no contienen marcas. Además, 


<banco-1> 

<cliente> 

<nombre-cliente> González </nombre-cliente> 
<calle-cliente> Arenal </calle-cliente> 

<ciudad-cliente> La Granja </ciudad-cllente> 

<cuenta> 

<número-cuenta> C-101 </número-cuenta> 
<nombre-sucursal> Centro </nombre-sucursal> 
<saldo> 500 </saldo> 

</cuenta> 

<cuenta> 

<número-cuenta> C-201 </número-cuenta> 
<nombre-sucursal> Galapagar </nombre-sucursal> 
<saldo> 900 </saldo> 

</cuenta> 

</cliente> 

<cliente> 

<nombre-cliente> López </nombre-cllente> 
<calle-cliente> Mayor </calle-cliente> 

<ciudad-cliente> PeguEtrerosos </ciudad-cllente> 
<cuenta> 

<número-cuenta> C-102 </número-cuenta> 
<nombre-sucursal> Navacerrada </nombre-sucursal> 
<saldo> 400 </saldo> 

</cuenta> 

</cliente> 

</banco-1> 

FIGURA 10.3. Representación XML anidada de información 
bancaria. 


ccuenta tipo-cuenta = «corriente»> 

<número-cuenta> C-102 </número-cuenta> 
<nombre-sucursal> Navacerrada </nombre-sucursal> 
<saldo> 400 </saldo> 

</cuenta> 

FIGURA 10.4. Uso de atributos. 

los atributos pueden aparecer solamente una vez en una 
etiqueta dada, al contrario que los subelementos, que 
pueden estar repetidos. 

Nótese que en un contexto de construcción de un 
documento es importante la distinción entre subele¬ 
mento y atributo; un atributo es implícitamente texto 
que no aparece en el documento impreso o visualiza¬ 
do. Sin embargo, en las aplicaciones de bases de datos 
y de intercambio de datos de XML esta distinción es 
menos relevante y la elección de representar los datos 
como un atributo o un subelemento es frecuentemente 
arbitraria. 

Una nota sintáctica final es que un elemento de la 
forma <elemento> </ elemente», que no contiene sube¬ 
lementos o texto, se puede abreviar como <elemento/>; 
los elementos abreviados pueden, no obstante, conte¬ 
ner atributos. 

Puesto que los documentos XML se diseñan para 
su intercambio entre aplicaciones se tiene que intro¬ 
ducir un mecanismo de espacio de nombres para per¬ 
mitir a las organizaciones especificar nombre únicos 
globalmente para que se usen como marcas de ele¬ 
mentos en los documentos. La idea de un espacio de 
nombres es anteponer cada etiqueta o atributo con un 
identificador de recursos universal (por ejemplo, una 
dirección Web). Por ello, por ejemplo, si Banco Prin¬ 
cipal deseara asegurar que los documentos XML crea¬ 
dos no duplican las etiquetas usadas por los docu¬ 
mentos de otros socios del negocio, se puede anteponer 
un identificador único con dos puntos a cada nombre 
de etiqueta. El banco puede usar un URL Web como 
el siguiente 

http ://www. BancoPrincipal .com 

como un identificador único. El uso de identificadores 
únicos largos en cada etiqueta puede ser poco conve¬ 
niente, por lo que el espacio de nombres estándar pro¬ 
porciona una forma de definir una abreviatura para los 
identificadores. 

En la Figura 10.5 el elemento raíz ( banco) tiene un 
atributo xmlns:BP, que declara que BP está definido 
como abreviatura para el URL dado anteriormente. Se 
puede usar entonces la abreviatura en varias marcas 
de elementos como se ilustra en la figura. 

Un documento puede tener más de un espacio de 
nombres, declarado como parte del elemento raíz. 
Se pueden asociar entonces elementos diferentes con 
espacios de nombres distintos. Se puede definir un espa- 
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cbanco xmlns:BP = «http://www.BancoPrincipal.com»> 
<BP:sucursal> 

<BP:nombresucursal> Centro </BP:nombresucursal> 
<BP:ciudadsucursal> Brooklyn </BP:ciudadsucursal> 
</BP:sucursal> 

</banco> 

FIGURA 10.5. Nombres únicos de etiqueta mediante el uso 
de espacios de nombres. 

ció de nombres predeterminado mediante el uso del atri¬ 
buto xmlns en lugar de xmlns:BP en el elemento raíz. 
Los elementos sin un prefijo de espacio de nombres 


explícito pertenecen entonces al espacio de nombres 
predeterminado. 

Algunas veces se necesitan almacenar valores que 
contengan etiquetas sin que sean interpretadas como 
etiquetas XML. XML permite esta construcción para 
ello: 

<![CDATA[<cuenta> ■■■ </cuenta>]]> 

Debido a que el texto <cuenta> está encerrado en CDA- 
TA, se trata como datos de texto normal, no como una 
etiqueta. El término CDATA viene de datos de carácter 
(character data en inglés). 


10.3. ESQUEMA DE LOS DOCUMENTOS XML 


Las bases de datos tienen esquemas que se usan para 
restringir qué información se puede almacenar en la base 
de datos y para restringir los tipos de datos de la infor¬ 
mación almacenada. En cambio, los documentos XML 
se pueden crear de forma predeterminada sin un esque¬ 
ma asociado. Un elemento puede tener entonces cual¬ 
quier subelemento o atributo. Aunque dicha libertad 
puede ser aceptable algunas veces, dada la naturaleza 
autodescriptiva del formato de datos, no es útil gene¬ 
ralmente cuando los documentos XML se deben pro¬ 
cesar automáticamente como parte de una aplicación o 
incluso cuando se van a dar formato en XML a grandes 
cantidades de datos relacionados. 

Aquí se describirá el mecanismo de esquema orien¬ 
tado a documentos incluido como parte del estándar 
XML, la definición de tipos de documento, así como 
XMLSchema, definido más recientemente. 

10.3.1. Definición de tipos de documento 

La definición de tipos de documento (Document Type 
Definition, DTD) es una parte opcional de un documento 
XML. El propósito principal de DTD es similar al de 
un esquema: restringir el tipo de información presente 
en el documento. Sin embargo, DTD no restringe en 
realidad los tipos en el sentido de tipos básicos como 


entero o cadena. En su lugar solamente restringe el 
aspecto de subelementos y atributos en un elemento. 
DTD es principalmente una lista de reglas que indican 
el patrón de subelementos que aparecen en un elemen¬ 
to. La Ligura 10.6 muestra una parte de una DTD de 
ejemplo de un documento de información bancaria; el 
documento XML en la Ligura 10.1 se ajusta a DTD. 

Cada declaración está en la forma de una expresión 
normal para los subelementos de un elemento. Así, en 
la DTD de la Ligura 10.6 un elemento bancario consis¬ 
te en uno o más elementos cuenta, cliente o impositor; 
el operador I especifica «o» mientras que el operador + 
especifica «uno o más». Aunque no se muestra aquí, el 
operador * se usa para especificar «cero o más» mien¬ 
tras que el operador ? se usa para especificar un ele¬ 
mento opcional (es decir, «cero o uno»). 

El elemento cuenta se define para contener los sube¬ 
lementos número-cuenta, nombre-sucursal y saldo (en 
ese orden). De forma similar, cliente e impositor tienen 
los atributos en su esquema definidos como subele¬ 
mentos. 

Linalmente, se declara a los elementos número-cuen¬ 
ta, nombre-sucursal, saldo, nombre-cliente, calle-clien¬ 
te y ciudad-cliente del tipo #PCDATA. La palabra cla¬ 
ve #PCDATA indica dato de texto; deriva su nombre 
históricamente de parsed character data (datos de carac- 


<!DOCTYPE banco [ 

clELEMENT banco ((cuenta Iclientel impositor)+)> 
clELEMENT cuenta ( número-cuenta nombre-sucursal saldo )> 
clELEMENT cliente ( nombre-cliente calle-cliente ciudad-cliente )> 
clELEMENT impositor ( nombre-cliente número-cuenta )> 
clELEMENT número-cuenta ( #PCDATA )> 
clELEMENT nombre-sucursal (#PCDATA)> 
clELEMENT saldo( #PCDATA )> 
clELEMENT nombre-cliente( #PCDATA )> 
clELEMENT calle-cliente( #PCDATA )> 
clELEMENT ciudad-cliente( #PCDATA )> 


FIGURA 10.6. Ejemplo de una DTD. 
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teres analizados). Otros dos tipos especiales de decla¬ 
raciones son empty (vacío), que dice que el elemento 
no tiene ningún contenido, y any (cualquiera), que indi¬ 
ca que no hay restricción sobre los subelementos del 
elemento; es decir, cualquier elemento, incluso los no 
mencionados en la DTD, puede ser subelemento del ele¬ 
mento. La ausencia de una declaración para un subele¬ 
mento es equivalente a declarar explícitamente el tipo 
como any. 

Los atributos permitidos para cada elemento también 
se declaran en la DTD. Al contrario que los subele¬ 
mentos no se impone ningún orden a los atributos. Los 
atributos se pueden especificar del tipo CDATA, ID, 
IDREF o IDREFS; el tipo CDATA simplemente dice que 
el atributo contiene datos de caracteres mientras que los 
otros tres no son tan sencillos; se explicarán detallada¬ 
mente en breve. Por ejemplo, la siguiente línea de una 
DTD especifica que el elemento cuenta tiene un atri¬ 
buto del tipo tipo-cuenta con valor predeterminado 
corriente. 

<!ATTLIST cuenta tipo-cuenta CDATA «corriente» > 

Los atributos siempre deben tener una declaración 
de tipo y una declaración predeterminada. La declara¬ 
ción predeterminada puede consistir en un valor prede¬ 
terminado para el atributo o #REQUIRED, queriendo 
esto decir que se debe especificar un valor para el atri¬ 
buto en cada elemento, #IMPLIED, lo que significa que 
no se ha proporcionado ningún valor predeterminado. 
Si un atributo tiene un valor predeterminado, para cada 
elemento que no tenga especificado un valor para el atri¬ 
buto el valor se rellena automáticamente cuando se lee 
el documento XML. 

Un atributo del tipo ID proporciona un identificador 
único para el elemento; un valor que tiene un atributo 
ID de un elemento no debe estar presente en ningún otro 
elemento del mismo documento. A lo sumo se permite 
que el atributo de un elemento sea del tipo ID. 

Un atributo del tipo IDREF es una referencia a un 
elemento; el atributo debe contener un valor que apa¬ 
rezca en el atributo ID de algún elemento en el docu¬ 
mento. El tipo IDREFS permite una lista de referencias, 
separadas por espacios. 


La Figura 10.7 muestra una DTD de ejemplo en la 
que las relaciones de la cuenta de un cliente se repre¬ 
sentan mediante los atributos ID e IDREFS en lugar de 
los registros impositor. Los elementos cuenta usan núme¬ 
ro-cuenta como su atributo identificador; para realizar 
esto se ha hecho que número-cuenta sea un atributo de 
cuenta en lugar de un subelemento. Los elementos clien¬ 
te tienen un nuevo atributo identificador denominado 
cliente-ID. Además, cada elemento cliente contiene un 
atributo cuentas del tipo IDREFS, que es una lista de 
identificadores de las cuentas que posee el cliente. Cada 
elemento cuenta tiene un atributo tenedores del tipo 
IDREFS, que es una lista de propietarios de la cuenta. 

La Figura 10.8 muestra un ejemplo de documento 
XMF basado en la DTD de la Figura 10.7. 

Nótese que se usa un conjunto distinto de cuentas y 
clientes del ejemplo anterior con el fin de ilustrar mejor 
la característica IDREFS. 

Fos atributos ID e IDREF juegan la misma función 
que los mecanismos de referencia en las bases de datos 
orientadas a objetos y las bases de datos relaciónales 
orientadas a objetos permitiendo la construcción de com¬ 
plejas relaciones de datos. 

Fas definiciones de tipos de documentos están fuerte¬ 
mente conectadas con la herencia del formato del docu¬ 
mento XMF. Debido a esto no son adecuadas por varios 
motivos para servir como estructura de tipos de XMF pa¬ 
ra aplicaciones de procesamiento de datos. No obstan¬ 
te, un tremendo número de formatos de intercambio de 
datos se están definiendo en términos de DTD, puesto que 
fueron parte original del estándar. Veamos algunas limi¬ 
taciones de las DTD como mecanismo de esquema. 

• No se pueden declarar el tipo de elementos y atri¬ 
butos de texto individuales. Por ejemplo, el elemento 
saldo no se puede restringir para que sea un núme¬ 
ro positivo. Fa falta de tal restricción es problemá¬ 
tica para las aplicaciones de procesamiento e inter¬ 
cambio de datos, las cuales deben contener el código 
para verificar los tipos de los elementos y atributos. 

• Es difícil usar el mecanismo DTD para especifi¬ 
car conjuntos desordenados de subelementos. El 
orden es rara vez importante para el intercambio 
de datos (al contrario que en el diseño de docu- 


<!DOCTYPE banco-2 [ 

<!ELEMENT cuenta ( sucursal, saldo )> 
clATTLIST cuenta 

número-cuenta ID #REQUIRED 
tenedores IDREFS #REQUIRED > 
clELEMENT cliente ( nombre-cliente, calle-cliente, ciudad-cliente )> 
clATTLIST cliente 

cliente-id ID #REQUIRED 
cuentas IDREFS #REQUIRED > 

■ ■ ■ declaraciones para sucursal, saldo, nombre-cliente, 
calle-cliente y ciudad-cliente ■ ■ ■ 


FIGURA 10.7. DTD con los tipos de atributo ID e IDREF. 
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<banco-2> 

<cuenta número-cuenta = «C-401» tenedores = «C100 C102»> 
<nombre-sucursal> Centro </nombre-sucursal> 

<saldo> 500 </saldo> 

</cuenta> 

<cuenta número-cuenta = «C-402» tenedores = «C102 C101 »> 
<nombre-sucursal> Navacerrada </nombre-sucursal> 
<saldo> 900 </saldo> 

</cuenta> 

<cliente cliente-id = «C100» cuentas = «C-401 »> 
<nombre-cliente>Juncal</nombre-cl¡ente> 

<calie-cliente> Mártires </calle-cliente> 

<ciudad-cliente> Melilla </ciudad-cliente> 

</cliente> 

<cliente cliente-id = «C101» cuentas = «C-402»> 
<nombre-cliente>Loreto</nombre-cliente> 

<calle-cliente> Montaña </calle-cliente> 

<ciudad-cliente> Cáceres </ciudad-cliente> 

</cliente> 

<cliente cliente-id = «C102» cuentas = «C-401 C-402»> 
<nombre-cliente>María</nombre-cl¡ente> 

<calie-cliente> Etreros </calie-cliente> 

<ciudad-cliente> Alicante </ciudad-cliente> 

</cliente> 

</banco-2> 

FIGURA 10.8. Datos XML con atributos ID e IDREF. 


mentos, donde es crucial). Aunque la combinación 
de la alternativa (la operación I) y la operación * 
como en la Figura 10.6 permite la especificación 
de colecciones desordenadas de marcas, es mucho 


más complicado especificar que cada marca pue¬ 
da aparecer solamente una vez. 

• Hay una falta de tipos en ID e IDREF. Por ello no 
hay forma de especificar el tipo de elemento al cual 
se debería referir una atributo IDREF o IDREFS. 
Como resultado, la DTD de la Figura 10.7 no evi¬ 
ta que el atributo «tenedores» de un elemento cuen¬ 
ta se refiera a otras cuentas, incluso si esto no tie¬ 
ne sentido. 

10.3.2. Esquema XML 

Un intento de reparar muchas de estas deficiencias de DTD 
produjo un lenguaje de esquema más sofisticado, XMLS- 
chema. Presentamos aquí un ejemplo de XMLSchema y 
se listan algunas áreas en las cuales mejora a las DTDs 
sin dar mucho detalle de la sintaxis de XMLSchema. 

La Figura 10.9 muestra cómo la DTD de la Figura 
10.6 se puede representar mediante XMLSchema. El 
primer elemento es el elemento raíz banco, cuyo tipo 
se declara posteriormente. En el ejemplo se definen des¬ 
pués los tipos de los elementos cuenta, cliente e impo- 
sitor. Obsérvese el uso de los tipos xsd:string y xsd:deci- 
mal para restringir los tipos de los elementos de datos. 
Finalmente, el ejemplo define el tipo TipoBanco para 
contener cero o más apariciones de cada cuenta, clien¬ 
te e impositor. XMLSchema puede definir el número 
mínimo y máximo de apariciones de subelementos 


<xsd:schema xmlns:xsd = «http://www.w3.org/2001/XMLSchema»> 

<xsd:element ñame = «banco» type = «TipoBanco» /> 

<xsd:element ñame = «cuenta»> 

<xsd:complexType> 

<xsd:sequence> 

<xsd:element ñame = «número-cuenta» type = «xsd:string»/> 

<xsd:element ñame = «nombre-sucursal» type = «xsd:string»/> 
<xsd:element ñame = «saldo» type = «xsd:decimal»/> 

</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:element ñame = «cliente»> 

<xsd:element ñame = «número-cliente» type = «xsd:string»/> 

<xsd:element ñame = «calle-cliente» type = «xsd:string»/> 

<xsd:element ñame = «ciudad-cliente» type = «xsd:string»/> 
</xsd:element> 

<xsd:element ñame = «impositor»> 

<xsd :complexType> 

<xsd:sequence> 

<xsd:element ñame = «nombre-cliente» type = «xsd:string»/> 

<xsd:element ñame = «número-cuenta» type = «xsd:string»/> 
</xsd:sequence> 

</xsd:complexType> 

</xsd:element> 

<xsd:complexType ñame = «TipoBanco»> 

<xsd:sequence> 

<xsd:element ref = «cuenta» minOccurs = «0» maxOccurs = «unbounded»/> 
<xsd:element ref = «cliente» minOccurs = «0» maxOccurs = «unbounded»/> 
<xsd:element ref = «impositor» minOccurs = «0» maxOccurs = «unbounded»/> 
</xsd:sequence> 

</xsd:complexType> 

</xsd:schema> 


FIGURA 10.9. Versión XMLSchema del DTD de la Figura 10.6. 
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mediante minOccurs y maxOccurs. El valor predeter¬ 
minado para las apariciones máxima y mínima es 1, por 
lo que se tiene que especificar explícitamente para per¬ 
mitir cero o más cuentas, impositores y clientes. 

Entre los beneficios que ofrece XMLSchema res¬ 
pecto a las DTDs se encuentran los siguientes: 

• Permite crear tipos definidos por el usuario 

• Permite que el texto que aparece en los elementos 
esté restringido a tipos específicos tales como tipos 
numéricos en formatos específicos o incluso tipos 
más complicados como listas o uniones. 

• Permite restringir los tipos para crear tipos espe¬ 
cializados, por ejemplo especificando valores míni¬ 
mo y máximo. 


• Permite la extensión de tipos complejos mediante 
el uso de una forma de herencia. 

• Es un superconjunto de DTDs. 

• Permite restricciones de unicidad y de clave exter¬ 
na. 

• Está integrado con espacios de nombres para per¬ 
mitir a diferentes partes de un documento adap¬ 
tarse a un esquema diferente. 

• El mismo se especifica mediante sintaxis XML 
como muestra la Figura 10.9. 

Sin embargo, el precio a pagar por estas caracterís¬ 
ticas es que XMLSchema es significativamente más 
complicado que las DTDs. 


10.4. CONSULTA Y TRANSFORMACIÓN 


Dado el creciente número de aplicaciones que usan 
XML para intercambiar, transmitir y almacenar datos, 
las herramientas para una gestión efectiva de datos XML 
están siendo cada vez más importantes. En particular 
las herramientas para consultar y transformar los datos 
XML son esenciales para extraer información de gran¬ 
des cuerpos de datos XML y para convertir los datos 
entre distintas representaciones (esquemas) en XML. 
Al igual que la salida de una consulta relacional es una 
relación, la salida de una consulta XML puede ser un 
documento XML. Como resultado, la consulta y la trans¬ 
formación se pueden combinar en una única herra¬ 
mienta. 

Varios lenguajes proporcionan grados crecientes de 
capacidades de consulta y transformación: 

• XPath es un lenguaje para expresiones de rutas de 
accesos y es realmente un bloque constructor los 
dos lenguajes de consulta restantes. 

• XSLT fue diseñado para ser un lenguaje de trans¬ 
formación como parte del sistema de hojas de esti¬ 
lo XSL, que se usa para controlar el formato de los 
datos XML en HTML u otro lenguaje de impre¬ 
sión o visualización. Aunque diseñado para el for¬ 
mato, XSLT puede generar XML como salida y 
puede expresar muchas consultas interesantes. Ade¬ 
más, es actualmente el lenguaje más ampliamen¬ 
te disponible para manipular datos XML. 

• XQuery ha sido propuesto como un estándar para 
consultar datos XML. XQuery combina las carac¬ 
terísticas de muchas propuestas anteriores para la 
consulta de XML, en particular el lenguaje Quilt. 

Se usa en todos estos lenguajes un modelo de árbol 
de datos XML. Un documento XML se modela como 
un árbol con nodos para los elementos y atributos. Los 


nodos elemento pueden tener nodos hijo, los cuales pue¬ 
den ser subelementos o atributos del elemento. De igual 
forma, cada nodo (ya sea atributo o elemento) distinto 
del elemento raíz tiene un nodo padre, que es un ele¬ 
mento. El orden de los elementos y atributos en el docu¬ 
mento XML se modela ordenando los nodos hijos de 
un árbol. Los términos padre, hijo, ascendiente, des¬ 
cendiente y hermano se interpretan en el modelo de árbol 
de datos XML. 

El contenido textual de un elemento se puede mode¬ 
lar como un nodo de texto hijo del elemento. Los ele¬ 
mentos que contienen texto descompuesto por subele¬ 
mentos intervinientes pueden tener varios nodos de 
texto hijo. Por ejemplo, un elemento que contenga 
«Éste es un <bold> buen </bold> libro» contiene un 
subelemento hijo correspondiente al elemento bold y 
dos nodos de texto hijo correspondientes a «Éste es 
un» y «libro». Puesto que dichas estructuras se usan 
comúnmente en los datos de una base de datos se asu¬ 
mirá que los elementos no contienen texto ni subele¬ 
mentos. 

10.4.1. XPath 

XPath trata partes de un documento XML mediante 
expresiones de rutas de acceso. Se puede ver el lenguaje 
como una extensión a las expresiones de rutas de acce¬ 
so sencillas en las bases de datos orientadas a objetos y 
relaciónales orientadas a objetos (véase el Apartado 
9.5.1). 

Una expresión de ruta en XPath es una secuencia 
de pasos de ubicación separados por «/» (en lugar del 
operador «.» que separa pasos en SQL: 1999). El resul¬ 
tado de la expresión de ruta es un conjunto de valores. 
Por ejemplo, en el documento de la Figura 10.8 la expre¬ 
sión XPath 
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/banco-2/cliente/name 

devolverá estos elementos: 

<name>Juncak/name> 

<name>Loreto</name> 

<name>María</name> 

La expresión 

/banco-2/cliente/name/text() 

devolverá los mismos nombres, pero sin las etiquetas 
de cierre. 

Como en una jerarquía de directorios el signo 7’ ini¬ 
cial indica la raíz del documento (nótese que esto es una 
raíz abstracta «sobre» <banco-2>, que es la marca del 
documento). Las expresiones de ruta se evalúan de 
izquierda a derecha. Cuando se evalúa la expresión de 
ruta el resultado de la ruta en cualquier punto consiste 
en un conjunto de nodos del documento. 

Cuando un nombre de elemento, tal como cliente, 
aparece antes de la siguiente 7’ se refiere a todos los 
elementos del nombre especificado que son hijos de ele¬ 
mentos en el conjunto de elementos actual. Puesto que 
varios hijos pueden tener el mismo nombre, el número 
de nodos en el conjunto de nodos puede aumentar o 
decrecer con cada paso. También se puede acceder a los 
valores de atributo mediante el uso del símbolo «@». 
Por ejemplo, /banco-2/cuenta/@número-cuenta devuel¬ 
ve un conjunto con todos los valores de los atributos 
número-cuenta de los elementos cuenta. De forma pre¬ 
determinada no se siguen los vínculos IDREF; poste¬ 
riormente veremos cómo tratar con IDREF. 

XPath soporta otras características: 

• La selección de predicados puede seguir cualquier 
paso en una ruta y están contenidos entre corche¬ 
tes. Por ejemplo 

/banco-2/cuenta[saldo > 400] 

devuelve los elementos cuenta con un valor saldo 
mayor que 400 mientras que 

/banco-2/cuenta[saldo > 400]/@número-cuenta 

devuelve los números de cuenta de dichas cuentas. 

Se puede comprobar la existencia de un sube¬ 
lemento mediante su listado sin ninguna operación 
de comparación; por ejemplo si se elimina «>400» 
de la expresión anterior devolvería los números de 
cuenta de todas las cuentas que tiene un subele¬ 
mento saldo, sin considerar su valor. 

• XPath proporciona varias funciones que se pueden 
usar como parte de predicados incluyendo la com¬ 
probación de la posición del nodo actual en el orden 


de los hermanos y contando el número de nodos 
coincidentes. Por ejemplo, la expresión de ruta 

/banco-2/cuenta/[cliente/count()> 2] 

devuelve las cuentas con más de dos clientes. Se 
pueden usar las conectivas lógicas and y or en los 
predicados y la función not(. ..) se puede usar para 
la negación. 

• La función id(«foo») devuelve el nodo (si existe) 
con un atributo del tipo ID y cuyo valor sea «foo». 
La función id se puede incluso aplicar a conjuntos 
de referencias o incluso a cadenas que contengan 
referencias múltiples separadas por espacios vací¬ 
os, tales como IDREFS. 

Por ejemplo, la ruta 

/banco-2/cuenta/id(@tenedores) 

devuelve todos los clientes referenciados desde el 
atributo tenedores de los elementos cuenta. 

• El operador I permite unir resultados de expresio¬ 
nes. Por ejemplo, si la DTD de banco-2 también 
contiene elementos para préstamos con atributo 
prestamista del tipo IDREFS para identificar el 
prestamista de un préstamo, la expresión 

/banco-2/cuenta/id(@tenedores) I /banco-2/ 
préstamo/id(@prestamista) 

proporciona los clientes con cuentas o préstamos. 
Sin embargo, el operador I no se puede anidar den¬ 
tro de otros operadores. 

• Una expresión XPath puede saltar varios niveles 
de nodos mediante el uso de «II». Por ejemplo la 
expresión /banco-2//name encuentra cualquier ele¬ 
mento ñame en cualquier lugar bajo el elemento 
/banco-2, sin considerar el elemento en el que está 
contenido. Este ejemplo ilustra la capacidad de 
buscar datos requeridos sin un conocimiento com¬ 
pleto del esquema. 

• Cada paso en la ruta no selecciona los hijos de los 
nodos del conjunto actual de nodos. En realidad 
esto es solamente una de las distintas direcciones 
que puede tomar un paso en la ruta tales como 
padres, hermanos, ascendientes y descendientes. 
Aquí se omiten los detalles, pero nótese que «II», 
descrito anteriormente, es una forma abreviada de 
especificar «todos los descendientes» mientras que 
«..» especifica el padre. 

10.4.2. XSLT 

Una hoja de estilo es una representación de las opcio¬ 
nes de formato para un documento, normalmente alma¬ 
cenado fuera del documento mismo, por lo que el for¬ 
mato está separado del contenido. Por ejemplo, una hoja 
de estilo para HTML podría especificar la fuente a usar 
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en todas la cabeceras y por ello reemplaza un gran núme¬ 
ro de declaraciones de fuente en la página HTML. XSL 
(XML Styleslieet Language), el lenguaje de hojas de 
estilo XML, estaba originalmente diseñado para gene¬ 
rar HTML a partir de XML y es por ello una extensión 
lógica de hojas de estilo HTML. El lenguaje incluye un 
mecanismo de transformación de propósito general, 
denominado XSLT (XSL Transformations, transfor¬ 
maciones XSL), que se puede usar para transformar un 
documento XML en otro documento XML, o a otros 
formatos como HTML 1 . Las transformaciones XSLT 
son bastante potentes y en realidad XSLT puede inclu¬ 
so actuar como un lenguaje de consulta. 

Las transformaciones XSLT se expresan como una 
serie de reglas recursivas, denominadas plantillas. 

En su forma básica las plantillas permiten la selec¬ 
ción de nodos en un árbol XML mediante una expre¬ 
sión XPath. Sin embargo, las plantillas también pueden 
generar contenido XML nuevo de forma que esa selec¬ 
ción y generación de contenido se pueda mezclar de for¬ 
mas naturales y potentes. Aunque XSLT se puede usar 
como un lenguaje de consulta, su sintaxis y semántica 
es bastante distinta a la de SQL. 

Una plantilla sencilla para XSLT consiste en una par¬ 
te de coincidencia (match) y una parte de selección 
(select). Consideremos el siguiente código XSLT. 

<xsl:template match = «/banco-2/cliente»> 
<xsl:value-of select = «nombre-cliente»/> 
</xsl:template> 

<xsl:template match = «*»/> 

La instrucción xshtemplate match contiene una expre¬ 
sión XPath que selecciona uno o más nodos. La prime¬ 
ra plantilla busca coincidencias de elementos cliente que 
aparecen como hijos del elemento raíz banco-2. La ins¬ 
trucción xsl:value-of encerrada en la instrucción de coin¬ 
cidencia devuelve valores de los nodos en el resultado 
de la expresión XPath. La primera plantilla devuelve el 
valor del subelemento nombre-cliente; nótese que el va¬ 
lor no contiene la marca element. 

Nótese que la segunda plantilla coincide con todos los 
nodos. Esto se requiere porque el comportamiento pre¬ 
determinado de XSLT sobre los elementos del documento 
de entrada que no coinciden con ninguna plantilla es 
copiar su contenido textual en el documento de salida y 
aplicar recursivamente las plantillas a sus subelementos. 

Cualquier texto o etiqueta de la hoja de estilo XSLT 
que no esté en el espacio de nombres xsl se copia a la 
salida sin cambios. La Ligura 10.10 muestra cómo usar 
esta característica para hacer que cada nombre de clien¬ 
te del ejemplo aparezca como un subelemento del ele¬ 
mento «<cliente»> mediante la ubicación de la instruc¬ 
ción xsl:value-of entre <cliente> y </cliente>. 


1 El estándar XSL ahora consiste en XSLT y un estándar para especi¬ 
ficar las características del formato tales como fuentes, márgenes de 
página y tablas. El formato no es relevante desde una perspectiva de 
las bases de datos, por lo que no se tratará aquí. 


<xsl:template match = «/banco-2/cliente»> 

<cliente> 

<xsl:value-of select = «nombre-cliente»/> 

</cliente> 

</xsl:template> 

<xsl:template match = «*»/> 

FIGURA 10.10. Uso de XSLT para convertir los resultados 
en nuevos elementos XML. 

La creación de un atributo, como id-Cliente, en el 
elemento Cliente generado, es más complicado y requie¬ 
re el uso de xsliattribute. Véase un manual de XSLT 
para más detalles. 

La recursividad estructural es una parte clave de 
XSLT. Hay que recordar que los elementos y subele¬ 
mentos naturalmente forman una estructura en árbol. 
La idea de la recursividad estructural es la siguiente: 
cuando una plantilla coincide con un elemento en la 
estructura de árbol XSLT puede usar la recursividad 
estructural para aplicar las reglas de la plantilla recur¬ 
sivamente a los subárboles en lugar de simplemente 
devolver un valor. Aplica las reglas recursivamente 
mediante la directiva xshapply-templates, que aparece 
dentro de otras plantillas. 

Por ejemplo, los resultados de nuestra consulta ante¬ 
rior se pueden ubicar en un elemento <clientes> median¬ 
te la adición de una regla usando xshapply-templates, 
como en la Ligura 10.11. La nueva regla coincide con 
la etiqueta externa «banco» y construye un documento 
resultado mediante la aplicación de otras plantillas a los 
subárboles que aparecen en el elemento banco, pero 
envolviendo los resultados en el elemento <clientes> 
</clientes> dado. Sin la recursividad forzada por la cláu¬ 
sula <xsl:apply-templates/> la plantilla devolvería <clien- 
tes> </clientes> y entonces aplicaría otras plantillas a 
los subelementos. 

En realidad, la recursividad estructural es crítica para 
construir documentos XML bien formados, puesto que 
los documentos XML deben tener un único elemento 
de nivel superior que contenga el resto de elementos del 
documento. 

XSLT proporciona una característica denominada 
key (clave), que permite la búsqueda de elementos 
mediante el uso de valores de subelementos o atributos; 
los objetivos son similares a los de la función id() en 
XPath, pero permite usar atributos distintos a los atri- 

<xsl:template match = «/banco»> 

<clientes> 

<xsl:apply-templates/> 

</clientes> 

</xsl:template> 

<xsl:template match = «/cliente»> 

<cliente> 

<xsl:value-of select = «nombre-cliente»/> 

</cliente> 

</xsl:template> 

<xsl:template match = «*»/> 

FIGURA 10.11. Aplicación recursiva de reglas. 
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butos ID. Las claves se definen mediante una directiva 
xsl:key la cual tiene tres partes, por ejemplo: 

<xsl:key ñame = «numcuenta» match = 
«cuenta» use= «número-cuenta»/> 

El atributo ñame se usa para distinguir claves distintas. 
El atributo match especifica los nodos a los que se apli¬ 
ca la clave. Finalmente, el atributo use especifica la 
expresión a usar como el valor de la clave. Nótese que 
la expresión no tiene que ser única para un elemento; 
esto es, más de un elemento puede tener el mismo valor 
de expresión. En el ejemplo la clave denominada num¬ 
cuenta especifica que el subelemento número-cuenta de 
cuenta se debería usar como una clave para esa cuenta. 

Las claves se pueden usar en plantillas como parte 
de cualquier patrón mediante la función key. Esta fun¬ 
ción toma el nombre de la clave y un valor y devuelve 
el conjunto de nodos que coinciden con ese valor. Por 
ello, el nodo XML para la cuenta «C-401» se puede refe- 
renciar como key («numcuenta», «C-401»). 

Las claves se pueden usar para implementar algunos 
tipos de reuniones, como en la Figura 10.12. El código 
de la figura se puede aplicar a datos XML en el forma¬ 
to de la Figura 10.1. Aquí la función key reúne los ele¬ 
mentos impositor con los elementos coincidentes clien¬ 
te y cuenta. El resultado de la consulta consiste en pares 
de elementos cliente y cuenta encerrados en elementos 
cuenta-cliente. 

XSLT permite ordenar los nodos. Un ejemplo senci¬ 
llo muestra cómo se usaría xsfsort en la hoja de estilo para 
devolver los elementos cliente ordenados por el nombre: 

<xsl:template match = «/banco»> 

<xsl:apply-templates select = «cliente»> 
<xsl:sort select = «nombre-cliente»/> 
</xsl:apply-templates> 

</xsl:template> 

<xsl:template match = «cliente»> 

<cliente> 

<xsl:value-of select = «nombre-cliente»/> 
<xsl:value-of select = «calle-cliente»/> 
<xsl:value-of select = «ciudad-cliente»/> 
</cliente> 

</xsl:template> 

<xsl:template match = «*»/> 


Aquí xsfapply-template tiene un atributo select que 
lo restringe para que sólo se aplique a los subelemen¬ 
tos cliente. La directiva xsksort en el elemento xsfapply- 
template hace que los nodos se ordenen antes de ser pro¬ 
cesados por el siguiente conjunto de plantillas. Existen 
opciones para permitir la ordenación sobre varios sube- 
lementos/attributes, por valor numérico y en orden des¬ 
cendente. 

10.4.3. XQuery 

El consorcio W3C (World Wide Web Consortium) está 
desarrollando XQuery, un lenguaje de consulta de 
XML. Nuestra discusión aquí está basada en un bos¬ 
quejo del lenguaje estándar, por lo que el estándar final 
puede diferir; sin embargo se espera que las principa¬ 
les características no cambien sustancialmente. El len¬ 
guaje XQuery se deriva de un lenguaje de consulta 
XML denominado Quilt; la mayor parte de las ca¬ 
racterísticas de XQuery que se analizan aquí son parte 
de Quilt. Quilt por sí mismo incluye características de 
lenguajes anteriores, tales como XPath, discutido en el 
Apartadol0.4., y otros dos lenguajes de consulta XML: 
XQL y XML-QL. 

A diferencia de XSLT, XQuery no representa con¬ 
sultas en XML. En su lugar se parece más a consultas 
SQL y se organizan en expresiones «FLWR» (pronun¬ 
ciado «flower», «flor» en inglés) que comprende cua¬ 
tro secciones: for, let, where y return. La sección for 
proporciona una serie de variables que cuyos valores 
son los resultados de expresiones XPath. Cuando se 
especifica más de una variable, los resultados incluyen 
el producto cartesiano de los valores posibles que las 
variables pueden tomar, haciendo la cláusula for simi¬ 
lar en espíritu a la cláusula from de la consulta SQL. 
La cláusula let simplemente permite que se asignen 
expresiones complicadas a los nombres de las variables 
por simplicidad de representación. La sección where, 
como la cláusula SQL where, ejecuta comprobaciones 
adicionales sobre las tupias reunidas de la sección for. 
Finalmente la sección return permite la construcción 
de resultados en XML. 

Una expresión FLWR sencilla que devuelve los 
números de cuentas para las cuentas corrientes está basa¬ 
da en el documento XML de la Figura 10.8, que usa ID 
e IDREFS: 


<xsl:key ñame = «numcuenta» match = «cuenta» use = «número-cuenta»/> 
<xsl:key ñame = «numcliente» match = «cliente» use = «nombre-cliente»/> 
<xsl:template match = «impositor»> 

<cuenta-cliente> 

<xsl:value-of select = key(«numcliente», «nombre-cliente»)/> 
<xsl:value-of select = key(«numcuenta», «número-cuenta»)/> 
</cuenta-cllente> 

</xsl:template> 

<xsl:template match = «*»/> 

FIGURA 10.12. Combinaciones en XSLT. 
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for $x in /banco-2/cuenta 

let $numcuenta : = $x/@número-cuenta 

where $x/saldo > 400 

return <número-cuenta> $numcuenta </número- 
cuenta> 

Puesto que esta consulta es sencilla, la cláusula let 
no es esencial y la variable $numcuenta en la cláusula 
return se podría remplazar con $x/@número-cuenta. 
Nótese además que, puesto que la cláusula for usa expre¬ 
siones XPath, se pueden producir selecciones en la 
expresión XPath. Por ello, una consulta equivalente pue¬ 
de tener solamente cláusulas for y return: 

for $x ín /banco-2/cuenta[saldo > 400] 
return <número-cuenta> $x/@número-cuenta 
</número-cuenta> 

Sin embargo, la cláusula let simplifica las consultas 
complejas. 

Las expresiones de ruta en XQuery pueden devolver 
un multiconjunto con nodos repetidos. La función dis- 
tinct aplicada a un multiconjunto devuelve un conjunto 
sin duplicación. La función distinct se puede usar inclu¬ 
so con una cláusula for. XQuery también proporciona 
funciones de agregado tales como sum y count que se 
pueden aplicar a colecciones tales como conjuntos y 
multiconjuntos. Aunque XQuery no proporciona una 
constructora group by, las consultas de agregado se 
pueden escribir mediante el uso de constructoras FLWR 
anidadas en lugar de agrupamientos; dejamos los deta¬ 
lles como ejercicio. Nótese también que las variables 
asignadas por las cláusulas let pueden tener valores de 
conjunto o multiconjunto si la expresión de ruta en el 
lado derecho devuelve un conjunto o un multiconjunto 
respectivamente. 

Las reuniones se especifican en XQuery de forma 
parecida a SQL. La reunión de elementos impositor, 
cuenta y cliente en la Figura 10.1, que se escribió en 
XSLT en el Apartado 10.4.2, se puede escribir en 
XQuery de la siguiente forma 

for $a in /banco/cuenta, 

$c in /banco/cliente, 

$i in /banco/impositor 

where $a/número-cuenta = $i/número-cuenta 
and $c/nombre-cliente = $i/nombre-cliente 
return <cuenta-cliente> $c $a </cuenta-cliente> 

La misma consulta se puede expresar con las seleccio¬ 
nes especificadas como selecciones XPath: 

for $a in /banco/cuenta, 

$c in /banco/cliente, 

$i in /banco/impositor[número-cuenta = 
$a/número-cuenta 

and nombre-cliente = $c/nombre-cliente] 
return <cuenta-cliente> $c $a</cuenta-cliente> 


Las expresiones XQuery FLWR se pueden anidar en 
la cláusula return con el fin de generar anidamientos 
de elementos que no aparecen en el documento origen. 
Esta característica es similar a las subconsultas anida¬ 
das en la cláusula from de las consultas SQL del Apar¬ 
tado 9.5.3. 

Por ejemplo, la estructura XML mostrada en la Figu¬ 
ra 10.3, con los elementos de la cuenta anidados en ele¬ 
mentos cliente, se puede generar a partir de la estructu¬ 
ra en la Figura 10.1 mediante esta consulta: 

<banco-1> 

for $c in /banco/cliente 

return 

<cliente> 

$c/* 

for $i in /banco/impositor[nombre-cliente = 
$c/nombre-cliente], 

$a in /banco/cuenta[número-cuenta = 
$i/número-cuenta] 
return $a 
</cliente> 

</banco-1> 

La consulta también introduce la sintaxis $c/*, que se 
refiere a todos los hijos del nodo, que está ligada a la 
variable $c. De forma similar, $c/text() proporciona el 
contenido textual de un elemento, sin las etiquetas. 

Las expresiones de ruta en XQuery están basadas 
en expresiones de ruta en XPath, pero XQuery pro¬ 
porciona algunas extensiones (que se pueden finalmente 
agregar al mismo XPath). Una de las extensiones de 
sintaxis útiles es el operador ->, que se puede usar para 
desreferenciar IDREFs, al igual que la función id(). Se 
puede aplicar el operador sobre un valor del tipo 
IDREFS para obtener un conjunto de elementos. Se 
puede usar, por ejemplo, para encontrar todas las cuen¬ 
tas asociadas con un cliente, con la representación 
ID/IDREFS de la información bancada. Dejamos los 
detalles al lector. 

En XQuery los resultados se pueden ordenar si se 
incluye una cláusula sortby al final de cualquier expre¬ 
sión; la cláusula especifica cómo se han de ordenar las 
instancias de esa expresión. Por ejemplo, esta consulta 
tiene como salida todos los elementos cliente ordena¬ 
dos por el subelemento ñame: 

for $c in /banco/cliente, 

return <cliente> $c/* </cliente> sortby(name) 

Para ordenar de forma decreciente podemos usar 
sortby(name descending). 

La ordenación se puede realizar en varios niveles de 
anidamiento. Por ejemplo se puede obtener una repre¬ 
sentación anidada de la información bancaria ordenada 
según el nombre del cliente, con las cuentas de cada 
cliente ordenadas según el número de cuenta, según 
sigue: 
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<banco-1> 

for $c in /banco/cliente 
return 
<cliente> 

$c/* 

for $d in /banco/impositor[nombre-cliente = 
$c/nombre-cliente], 

$a in /banco/cuenta[número-cuenta = 
$d/número-cuenta] 

return <cuenta> $a/* </cuenta> sortby 
(número-cuenta) 

</cliente> sortby(nombre-cliente) 

</banco-1> 

XQuery proporciona una serie de funciones incor¬ 
poradas y soporta funciones definidas por el usuario. 
Por ejemplo, la función incorporada document(name) 
devuelve la raíz de un documento con nombre; la raíz 
se puede usar entonces en una expresión de ruta para 
acceder al contenido del documento. Los usuarios pue¬ 
den definir funciones tal como se ilustra con esta fun¬ 
ción, que devuelve una lista de todos los saldos de un 
cliente con un nombre especificado: 


function saldos(xsd:string $c) returns list(xsd: 
numeric) { 

for $i in /banco/impositor[nombre-cliente = $c], 

$a in /banco/cuenta[número-cuenta = 
$i/número-cuenta] 
return $a/saldo 

} 

XQuery usa el sistema de tipos de XMLSchema. 
XQuery también proporciona funciones para realizar 
conversiones entre tipos. Por ejemplo, number(x) con¬ 
vierte una cadena a un número. XQuery ofrece una 
gran variedad de otras características, tales como cláu¬ 
sulas if-then-else, las cuales se pueden usar con cláu¬ 
sulas return, y la cuantificación existencial y univer¬ 
sal, que se pueden usar en predicados en cláusulas 
where. Por ejemplo, la cuantificación existencial se 
puede expresar mediante el uso de some $e in path 
satisfies P donde path es una expresión de ruta y P es 
un predicado que puede usar $e. La cuantificación uni¬ 
versal se puede expresar mediante el uso de every en 
lugar de some. 


10.5. LA INTERFAZ DE PROGRAMACIÓN DE APLICACIONES 


Debido a la gran aceptación de XML como una repre¬ 
sentación de datos y formato de intercambio hay gran 
cantidad de herramientas de software disponibles para 
la manipulación de datos XML. En realidad hay dos 
modelos estándar para la manipulación mediante pro¬ 
gramación de XML, cada uno disponible para su uso 
con una gran cantidad de lenguajes de programación 
populares. 

Una de las API estándar para la manipulación XML 
es el modelo de objetos documento (Document Object 
Model, DOM), que trata el contenido XML como un 
árbol, con cada elemento representado por un nodo, 
denominado DOMNode. Los programas pueden acce¬ 
der a partes del documento mediante navegación comen¬ 
zando con la raíz. 

Hay disponibles bibliotecas DOM para los len¬ 
guajes de programación más comunes y están incluso 
presentes en los exploradores Web, donde se pueden 
usar para manipular el documento mostrado al usua¬ 
rio. Aquí se explican algunas de las interfaces y méto¬ 
dos de la API DOM de Java, para mostrar cómo pue¬ 
de ser un DOM. La API DOM de Java proporciona una 
interfaz denominada Node e interfaces Element y Attri- 
bute las cuales heredan de la interfaz Node. La inter¬ 
faz Node proporciona métodos tales como getParent- 
Node(), getFirstChild() y getNextSibling() para navegar 
por el árbol DOM comenzando por el nodo raíz. Se 
puede acceder a los subelementos de un elemento 
mediante el nombre getElementsByTagName(name) 


que devuelve una lista de todos los elementos hijo con 
un nombre de etiqueta especificado; se puede acceder 
a los miembros individuales de la lista mediante el 
método hijo, que devuelve el í-ésimo elemento en la 
lista. Se puede acceder a los valores de atributo de un 
elemento mediante el nombre, usando el método getAt- 
tribute(name). El valor de texto de un elemento se 
modela como un nodo Text, que es un hijo del nodo 
elemento; un nodo elemento sin subelemento tiene sola¬ 
mente un nodo hijo. El método getData() del nodo Text 
devuelve el contenido de texto. DOM también propor¬ 
ciona una serie de funciones para actualizar el docu¬ 
mento mediante la adición y el borrado de hijos ele¬ 
mento y atributo, el establecimiento de valores de 
nodos, etc. 

Se requieren muchos más detalles para escribir un 
programa DOM real; véanse las notas bibliográficas 
para obtener referencias con más información. 

DOM se puede usar para acceder a los datos XML 
almacenados en las bases de datos y se puede construir 
una base de datos XML mediante el uso de DOM como 
su interfaz principal para acceder y modificar los datos. 
Sin embargo, la interfaz DOM no soporta ninguna for¬ 
ma de consulta declarativa. 

La segunda interfaz de programación que discutire¬ 
mos, API simple para XML (Simple API for XML, 
SAX) es un modelo de eventos diseñado para propor¬ 
cionar una interfaz común entre analizadores y apli¬ 
caciones. Esta API está construida bajo la noción de 
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manejadores de eventos, que consisten en funciones 
especificadas por el usuario asociadas con eventos de 
análisis. Los eventos de análisis corresponden con el 
reconocimiento de partes de un documento; por ejem¬ 
plo, se genera un evento cuando se encuentra la etique¬ 


ta de inicio para un elemento y se genera otro evento 
cuando se encuentra la etiqueta de finalización. Las pie¬ 
zas de un documento siempre se encuentran en orden 
desde el inicio al final. SAX no es adecuado para apli¬ 
caciones de bases de datos. 


10.6. ALMACENAMIENTO DE DATOS XML 


Muchas aplicaciones requieren el almacenamiento de datos 
XML. Una forma de almacenar datos XML es convertir¬ 
los a una representación relacional y almacenarlos en una 
base de datos relacional. Hay varias alternativas para alma¬ 
cenar datos XML, las cuales se muestran brevemente aquí. 

10.6.1. Bases de datos relaciónales 

Puesto que las bases de datos relaciónales se usan 
ampliamente en aplicaciones existentes es una gran ven¬ 
taja almacenar datos XML en bases de datos relacióna¬ 
les de forma que se pueda acceder a los datos desde apli¬ 
caciones existentes. 

La conversión de datos XML a una forma relacional 
es normalmente muy sencilla si los datos se han gene¬ 
rado en un principio desde un esquema relacional y XML 
se usó simplemente como un formato de intercambio de 
datos para datos relaciónales. Sin embargo, hay muchas 
aplicaciones donde los datos XML no se han generado 
desde un esquema relacional y la traducción de los datos 
a una forma relacional de almacenamiento puede no ser 
tan sencilla. En particular los elementos anidados y los 
elementos que se repiten (correspondientes a atributos 
con valores de conjunto) complican el almacenamiento 
de los datos XML en un formato relacional. Hay dispo¬ 
nibles diversas alternativas. 

• Almacenamiento como cadena. Una forma sen¬ 
cilla de almacenar los datos XML en una base de 
datos relacional es almacenar cada elemento hijo 
del elemento de mayor nivel como una cadena en 
una tupia separada de la base de datos. Por ejem¬ 
plo, los datos XML de la Figura 10.1 se podrían 
almacenar como un conjunto de tupias en una rela¬ 
ción elementosfdatos), con el atributo datos de 
cada tupia almacenando un elemento XML (cuen¬ 
ta, cliente o impositor) en forma de cadena. 

Aunque esta representación es fácil de usar, el 
sistema de la base de datos no conoce el esquema 
de los elementos almacenados. Como resultado no 
es posible consultar los datos directamente. En rea¬ 
lidad no es siquiera posible implementar selec¬ 
ciones sencillas tales como buscar todos los ele¬ 
mentos cuenta o encontrar el elemento cuenta cuyo 
número de cuenta sea C-401, sin explorar todas las 
tupias de la relación y examinar los contenidos de 
la cadena almacenada en la tupia. 


Una solución parcial a este problema es alma¬ 
cenar distintos tipos de elementos en relaciones dife¬ 
rentes y también almacenar los valores de algunos 
elementos críticos como atributos de la relación que 
permite la indexación. Así, en nuestro ejemplo, las 
relaciones serían elementos-cuenta, elementos-clien¬ 
te y elementos-impositor, cada una con un atributo 
datos. Cada relación puede tener atributos extra para 
almacenar los valores de algunos subelementos tales 
como número-cuenta o nombre-cliente. Por ello se 
puede responder eficientemente con esta represen¬ 
tación a una consulta que requiera los elementos 
cuenta con un número de cuenta especificado. Tal 
enfoque depende del tipo de información sobre los 
datos XML, tales como la DTD de los datos. 

Algunos sistemas de bases de datos, tales como 
Oracle 9, soportan índices de función, que pue¬ 
den ayudar a evitar la duplicación de atributos entre 
la cadena XML y los atributos de la relación. A 
diferencia de los índices normales, que se cons¬ 
truyen sobre los valores de atributos, los índices 
de función se pueden construir sobre el resultado 
de aplicar funciones definidas por el usuario a las 
tupias. Por ejemplo, se puede construir un índice 
de función sobre una función definida por el usua¬ 
rio que devuelve el valor del subelemento núme¬ 
ro-cuenta de la cadena XML en una tupia. El índi¬ 
ce se puede entonces usar de la misma forma que 
un índice sobre un atributo número-cuenta. 

Estos enfoques tienen el inconveniente de que 
una gran parte de la información XML se almace¬ 
na en cadenas. Es posible almacenar toda la infor¬ 
mación en relaciones según alguna de las siguien¬ 
tes formas que se examinan a continuación. 

• Representación en árbol. Los datos XML arbi¬ 
trarios se pueden modelar como un árbol y alma¬ 
cenar mediante el uso de un par de relaciones: 

nodos(id, tipo, etiqueta, valor) 
hijo(id-hijo, id-padre) 

A cada elemento y atributo de los datos XML se 
le proporciona un identificador único. Una tupia 
insertada en la relación nodos para cada elemento 
y atributo con su identificador (id), su tipo ( atribu¬ 
to o elemento), el nombre del elemento o atributo 
(etiqueta) y el valor textual del elemento o atribu- 
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to (valor). La relación hijo se usa para guardar el 
elemento padre de cada elemento y atributo. Si la 
información de orden de los elementos y atributos 
se debe preservar, se puede agregar un atributo extra 
posición a la relación hijo para indicar la posición 
relativa del hijo entre los hijos del padre. Como ejer¬ 
cicio se pueden representar los datos XML de la 
Figura 10.1 mediante el uso de esta técnica. 

Esta representación tiene la ventaja de que toda 
la información XML se puede representar direc¬ 
tamente de forma relacional y se pueden trasladar 
muchas consultas XML a consultas relaciónales y 
ejecutar dentro del sistema de la base de datos. Sin 
embargo, tiene el inconveniente de que cada ele¬ 
mento se divide en muchas piezas y se requieren 
un gran número de combinaciones para reensam¬ 
blar los elementos. 

• Asignación a relaciones. Según este enfoque los 
elementos XML cuyo esquema es conocido se asig¬ 
nan a relaciones y atributos. Los elementos cuyo 
esquema es desconocido se almacenan como cade¬ 
nas o como una representación en árbol. 

Se crea una relación para cada tipo de elemen¬ 
to cuyo esquema sea conocido. Todos los atribu¬ 
tos de estos elementos se almacenan como atribu¬ 
tos de la relación. Todos los subelementos que 
suceden más de una vez dentro de estos elemen¬ 
tos (según se especifica en DTD) también se pue¬ 
den representar como atributos de la relación; si el 
subelemento puede contener solamente texto, el 
atributo almacena el valor de texto. En otro caso, 
la relación correspondiente al subelemento alma¬ 
cena los contenidos del subelemento junto con un 
identificador para el tipo padre y el atributo alma¬ 
cena el identificador del subelemento. Si el sube¬ 
lemento tiene más subelementos anidados se apli¬ 
ca el mismo procedimiento al subelemento. 

Si un subelemento puede aparecer varias veces 
en un elemento, el enfoque de asignación a rela¬ 
ciones almacena el contenido de los subelementos 
en la relación correspondiente al subelemento. Pro¬ 
porciona identificadores únicos tanto para el padre 
como para el subelemento y crea una relación sepa¬ 


rada, similar a la relación hijo vista en la repre¬ 
sentación en árbol anterior para identificar el sube¬ 
lemento que aparece bajo cada padre. Nótese que 
cuando se aplica este enfoque a la DTD de los 
datos en la Figura 10.1 se vuelve al esquema rela¬ 
cional original que se ha usado en capítulos ante¬ 
riores. Las notas bibliográficas proporcionan refe¬ 
rencias a tales enfoques híbridos. 

10.6.2. Almacenamientos de datos 
no relaciónales 

Hay varias alternativas para almacenar datos XML en 
sistemas de almacenamientos de datos no relaciónales: 

• Almacenamiento en archivos planos. Puesto que 
XML es principalmente un formato de archivo, un 
mecanismo de almacenamiento natural es simple¬ 
mente un archivo plano. Este enfoque tiene muchos 
de los inconvenientes mostrados en el Capítulo 1 
sobre el uso de sistemas de archivos como base para 
las aplicaciones de bases de datos. En particular 
hay una carencia de aislamiento de datos, compro¬ 
baciones de integridad, atomicidad, acceso concu¬ 
rrente y seguridad. Sin embargo, la amplia dispo¬ 
nibilidad de herramientas XML que funcionan sobre 
archivos de datos hace relativamente sencillo el 
acceso y consulta de datos XML almacenados en 
archivos. Por ello, este formato de almacenamien¬ 
to puede ser suficiente para algunas aplicaciones. 

• Almacenamiento en una base de datos XML. 

Las bases de datos XML son bases de datos que 
usan XML como su modelo de datos básico. Las 
bases de datos XML antiguas implementaban el 
modelo de objetos documento sobre una base de 
datos orientada a objetos basada en C++. Esto per¬ 
mite reusar gran parte de la infraestructura de bases 
de datos orientada a objetos mientras se usa una 
interfaz XML estándar. La adición de un lenguaje 
de consulta XML proporciona consultas declara¬ 
tivas. También es posible construir bases de datos 
XML como una capa en la parte superior de las 
bases de datos relaciónales. 


10.7. APLICACIONES XML 


Un objetivo central en el diseño para XML es hacer más 
sencillo comunicar la información en Web y entre apli¬ 
caciones permitiendo que la semántica de los datos se 
describa con los mismos datos. Por ello, aunque la gran 
cantidad de datos XML y su uso en aplicaciones de 
negocios indudablemente requerirán y se beneficiarán 
de las tecnologías de bases de datos XML, es princi¬ 
palmente un medio de comunicación. Dos aplicaciones 
XML para comunicación (intercambio de datos y media¬ 
ción de recursos de información Web) ilustran cómo 


XML logra su objetivo de soportar el intercambio de 
datos y demuestran cómo la tecnología e interacción de 
las bases de datos son la clave en dar soporte a aplica¬ 
ciones basadas en el intercambio. 

10.7.1. Intercambio de datos 

Se están desarrollando estándares para la representa¬ 
ción XML de los datos de una gran variedad de aplica¬ 
ciones especializadas que van desde aplicaciones de 
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negocios tales como banca y transportes a aplicaciones 
científicas tales como química y biología molecular. 
Veamos algunos ejemplos: 

• La industria química necesita información sobre 
los compuestos químicos tales como su estructu¬ 
ra molecular y una serie de propiedades impor¬ 
tantes tales como los puntos de fusión y ebullición, 
valores caloríficos, solubilidad en distintos sol¬ 
ventes y cosas así. ChemML es un estándar para 
representar dicha información. 

• En el transporte, los transportes de mercancías y 
los agentes de aduana e inspectores necesitan los 
registros de los envíos que contengan información 
detallada sobre los bienes que están siendo trans¬ 
portados, por quién y desde dónde se han envia¬ 
do, a quién y a dónde se envían, el valor moneta¬ 
rio de los bienes y cosas así. 

• Un mercado en línea en que los negocios pueden 
vender y comprar bienes (el llamado mercado B2B 
[business-to-business, de negocio a negocio]) 
requiere información tal como los catálogos de 
producto, incluyendo descripciones detalladas de 
los productos e información de los precios, inven¬ 
tarios de los productos, ofertas a comprar y cuo¬ 
tas para una venta propuesta. 

El uso de esquemas relaciónales normalizados para 
modelar requisitos de datos tan complejos genera un 
gran número de relaciones que son complicadas de ges¬ 
tionar por los usuarios. Las relaciones frecuentemente 
tienen un gran número de atributos; la representación 
explícita de nombres de atributos y elementos con sus 
valores en XML ayuda a evitar confusiones entre los 
atributos. Las representaciones de elementos anidados 
ayudan a reducir el número de relaciones que se deben 
representar, así como el número de combinaciones 
requeridas para obtener la información, con el posible 
coste de redundancia. Así, en nuestro ejemplo bancario 
el listado de clientes con elementos cuenta anidados en 
elementos cuenta, como en la Ligura 10.3, resulta en un 
formato que es más natural para algunas aplicaciones, 
en particular para su legibilidad, que lo que es la repre¬ 
sentación normalizada de la Ligura 10.1. 

Cuando se usa XML para intercambiar los datos entre 
aplicaciones de negocio los datos se originan muy fre¬ 
cuentemente en bases de datos relaciónales. Los datos 
en las bases de datos relaciónales deben ser publicadas, 
esto es, convertidos a formato XML para su exporta¬ 
ción a otras aplicaciones. Los datos de entrada deben 
ser despiezados, es decir, convertida desde XML a un 
formato normalizado de relación y almacenado en una 
base de datos relacional. Aunque el código de la apli¬ 
cación pueda ejecutar las operaciones de publicación y 
despiece, las operaciones son tan comunes que la con¬ 
versión se debería realizar de forma automática, sin 
escribir ningún código en la aplicación, siempre que sea 


posible. Por ello, los fabricantes de bases de datos están 
trabajando para dar capacidades XML a sus productos 
de bases de datos. 

Una base de datos con capacidades XML permite 
una correspondencia automática de su modelo relacio¬ 
nal interno (relacional, relacional orientado a objetos u 
orientado a objetos) con XML. Estas correspondencias 
pueden ser sencillas o complejas. Una correspondencia 
sencilla podría asignar un elemento a cada fila de una 
tabla y hacer de cada columna en esa fila bien un atri¬ 
buto o bien un subelemento del elemento de la fila. 
Dicha correspondencia es sencilla de generar automá¬ 
ticamente. Una correspondencia más complicada nece¬ 
sitaría que se crearan estructuras anidadas. Las exten¬ 
siones de SQL con consultas anidadas en la cláusula 
select se han desarrollado para permitir una creación 
fácil de salidas XML anidadas. Algunos productos de 
bases de datos permiten a las consultas XML acceder a 
los datos relaciónales tratando la forma XML de los 
datos relaciónales como un documento XML virtual. 

10.7.1.1. Mediación de datos 

La compra comparada es un ejemplo de aplicación de 
mediación de datos en la que los datos sobre elemen¬ 
tos, inventario, precio y costes de envío se extraen de 
una serie de sitios Web que ofrecen un elemento en par¬ 
ticular de venta. La información agregada resultante es 
significativamente más valiosa que la información indi¬ 
vidual ofrecida por un único sitio. 

Un gestor financiero personal es una aplicación simi¬ 
lar en el contexto de la banca. Consideremos un consu¬ 
midor con una gran cantidad de cuentas a gestionar, tales 
como cuentas bancarias, cuentas de ahorro y cuentas de 
jubilación. Supongamos que estas cuentas pueden estar 
en distintas instituciones. Es un reto importante pro¬ 
porcionar una gestión centralizada de todas las cuentas 
de un cliente. La mediación basada en XML soluciona 
el problema extrayendo una representación XML de la 
información de la cuenta desde los sitios Web respecti¬ 
vos de las instituciones financieras donde están las cuen¬ 
tas individuales. Esta información se puede extraer fácil¬ 
mente si la institución la exporta a un formato XML 
estándar, e indudablemente algunas lo harán. Para aque¬ 
llas que no lo hacen se usa un software envolvente para 
generar datos XML a partir de las páginas Web HTML 
devueltas por el sitio Web. Las aplicaciones envolven¬ 
tes necesitan un mantenimiento constante, puesto que 
dependen de los detalles de formato de las páginas Web, 
que cambian constantemente. No obstante, el valor pro¬ 
porcionado por la mediación frecuentemente justifica 
el esfuerzo requerido para desarrollar y mantener las 
aplicaciones envolventes. 

Una vez que las herramientas básicas están disponi¬ 
bles para extraer la información de cada fuente, se usa 
una aplicación mediadora para combinar la información 
extraída bajo un único esquema. Esto puede requerir 
más transformación de los datos XML de cada sitio, 
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puesto que los distintos sitios pueden estructurar la mis¬ 
ma información de una forma diferente. Por ejemplo, 
uno de los bancos puede exportar información en el for¬ 
mato de la Figura 10.1 aunque otros pueden usar la for¬ 
mato anidado de la Figura 10.3. También pueden usar 
nombres diferentes para la misma información (por 
ejemplo num-cuenta e id-cuenta), o pueden incluso usar 
el mismo nombre para información distinta. El media¬ 


dor debe decidir sobre un único esquema que represen¬ 
ta toda la información requerida, y debe proporcionar 
código para transformar los datos entre diferentes repre¬ 
sentaciones. Dichos temas se discutirán con mayor deta¬ 
lle en el Apartado 19.8 en el contexto de bases de datos 
distribuidas. Los lenguajes de consulta XML tales como 
XSLT y XQuery juegan un papel importante en la tarea 
de transformación entre distintas representaciones XML. 


10.8. RESUMEN 


• Al igual que el lenguaje de marcas de hipertexto, 
HTML ( Hyper-Text Markup Lcinguage), en que está 
basado Web, el lenguaje de marcas extensible, XML 
(Extensible Markup Language), es un descendiente 
del lenguaje estándar generalizado de marcas (SGML, 
Standard Generalized Markup Language). XML tuvo 
la intención original de proporcionar marcas funcio¬ 
nales para documentos Web, pero se ha convertido 
ahora en un formato de datos estándar para el inter¬ 
cambio entre aplicaciones. 

• Los documentos XML contienen elementos con eti¬ 
quetas de inicio y finalización correspondientes que 
indican el comienzo y finalización de un elemento. 
Los elementos puede tener subelementos anidados a 
ellos, a cualquier nivel de anidamiento. Los elemen¬ 
tos pueden también tener atributos. La elección entre 
representar información como atributos y subele¬ 
mentos es frecuentemente arbitraria en el contexto de 
la representación de datos. 

• Los elementos pueden tener un atributo del tipo ID 
que almacene un identificador único para el elemen¬ 
to. Los elementos también pueden almacenar refe¬ 
rencias a otros elementos mediante el uso de atribu¬ 
tos del tipo IDREF. Los atributos del tipo IDREFS 
pueden almacenar una lista de referencias. 

• Los documentos pueden opcionalmente tener su 
esquema especificado mediante una definición de tipos 
de documento (DTD, Document Type Declaration). 
La DTD de un documento especifica los elementos 
que pueden aparecer, cómo se pueden anidar y los 
atributos que puede tener cada elemento. 

• Aunque los DTDs se usan ampliamente, tienen varias 
limitaciones. Por ejemplo, no proporcionan un siste¬ 
ma de tipos. XMLSchema es un nuevo estándar para 
especificar el esquema de un documento. Aunque 
proporciona mayor potencia expresiva, incluyendo 
un potente sistema de tipos, también es más compli¬ 
cado. 

• Los datos XML se pueden representar como estruc¬ 
turas en árbol, como nodos correspondientes a los ele¬ 
mentos y atributos. El anidamiento de elementos se 
refleja mediante la estructura padre-hijo de la repre¬ 
sentación en árbol. 


• Las expresiones de ruta se pueden usar para recorrer 
la estructura de árbol XML y así localizar los datos 
requeridos. XPath es un lenguaje estándar para las 
expresiones de rutas de acceso y permite especificar 
los elementos requeridos mediante una ruta parecida 
a un sistema de archivos y además permite la selec¬ 
ción y otras características. XPath también forma par¬ 
te de otros lenguajes de consulta XML. 

• El lenguaje XSLT se diseñó originalmente como el 
lenguaje de transformación para una aplicación de 
hojas de estilo, en otras palabras, para aplicar infor¬ 
mación de formato a documentos XML. Sin embar¬ 
go, XSLT ofrece características bastante potentes 
de consulta y transformación y está ampliamente 
disponible, por lo que se usa para consultar datos 
XML. 

• Los programas XSLT contienen una serie de planti¬ 
llas, cada una con una parte match y una parte select. 
Cada elemento en la entrada de datos XML se com¬ 
prueba con las plantillas disponibles y se aplica al ele¬ 
mento la parte de la selección de la primera plantilla 
coincidente. 

Las plantillas se pueden aplicar recursivamente 
desde el cuerpo de otra plantilla, un procedimiento 
conocido como recursividad estructural. XSLT sopor¬ 
ta claves que se pueden usar para implementar algu¬ 
nos tipos de reuniones. También soporta la ordena¬ 
ción y otras características de consulta. 

• El lenguaje XQuery, que se está convirtiendo actual¬ 
mente en un estándar, está basado en el lenguaje de 
consulta Quilt. El lenguaje XQuery es similar a SQL, 
con cláusulas for, let, where y return. 

Sin embargo, soporta muchas extensiones para tra¬ 
tar con la naturaleza en árbol de XML y para permi¬ 
tir la transformación de documentos XML en otros 
documentos con una estructura significativamente 
diferente. 

• Los datos XML se pueden almacenar de varias for¬ 
mas distintas. Por ejemplo, los datos XML se pueden 
almacenar como cadenas en una base de datos rela- 
cional. De forma alternativa las relaciones pueden 
representar los datos XML como árboles. Como otra 
alternativa, los datos XML se pueden hacer corres- 
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ponder con relaciones de la misma forma que se hacen 
corresponder los esquemas E-R con esquemas rela¬ 
ciónales. 

Los datos XML también se pueden almacenar en 
sistemas de archivos o en bases de datos XML, las 
cuales usan XML como su representación interna. 


• La capacidad de transformar documentos en lengua¬ 
jes como XSLT y XQuery es clave para el uso de 
XML en aplicaciones de mediación tales como inter¬ 
cambios electrónicos de negocios y la extracción y 
combinación de datos Web para su uso por un gestor 
financiero personal o compra comparada. 


TÉRMINOS DE REPASO 


• Almacenamiento de datos XML 

— En bases de datos relaciónales 

- Almacenamiento como cadena 

- Representación en árbol 

- Asignación a relaciones 

— En almacenamientos de datos no relaciónales 

- Archivos 

- Bases de datos XML 

• API simple para XML (Simple API for XML, SAX) 

• API XML 

• Aplicaciones XML 

— Intercambio de datos 

- Publicación y despiece 

— Mediación de datos 

- Software envolvente 

• Atributos 

• Autodocumentado 

• Base de datos con capacidades XML 

• Consulta y transformación 

• Definición del esquema 

— Definición de tipos de documento (Document 
Type Definition, DTD) 

— XMLSchema 

• Elemento 

• Elemento raíz 

• Elementos anidados 

• Espacio de nombres 

• Espacio de nombres predeterminado 

• Expresiones de ruta 

• Hoja de estilo 

• ID 


• IDREFe IDREFS 

• Lenguaje de marcas 

• Lenguaje de marcas de hipertexto (Hyper-Text Mar- 
kup Language, HTML) 

• Lenguaje de marcas extensible (Extensible Markup 
Language, XML) 

• Lenguaje estándar generalizado de marcas (Standard 
Generalized Markup Language, SGML) 

• Marcas 

• Modelo de árbol de datos XML 

• Modelo de objetos documento (Document Object 
Model, DOM) 

• Nodos 

• Transformaciones XSL (XSL Transformations, XSLT) 

— Plantillas 

- match (coincidencia) 

- select (selección) 

— Recursividad estructural 

— Claves 

— Ordenación 

• XPath 

• XQuery 

— Expresiones LLWR 

- for 

- let 

- where 

- return 

— Reuniones 

— Expresión LLWR anidada 

— Ordenación 

• XSL (XML Stylesheet Language), lenguaje de hojas 
de estilo XML 
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EJERCICIOS 


10.1 Dese una representación alternativa de la información 
bancaria que contenga los mismos datos que en la Figu¬ 
ra 10.1, pero usando atributos en lugar de subelemen¬ 
tos. Dese también la DTD para esta representación. 

10.2 Demuéstrese, proporcionando una DTD, cómo repre¬ 
sentar la relación anidada libros del Apartado 9.1 
mediante el uso de XML. 

10.3 Dese la DTD para una representación XML del 
siguiente esquema relacional anidado 

Emp = (nombree, ConjuntoHijos setof (Hijos), Con- 
juntoMaterias setof {Materias)) 

Hijos = ( nombre, Cumpleaños) 

Cumpleaños = {día, mes, año) 

Materias = {tipo, ConjuntoExámenes setof {Exáme¬ 
nes)) 

Exámenes = {año, ciudad) 

10.4 Escríbanse las siguientes consultas en XQuery, asu¬ 
miendo la DTD del Ejercicio 10.3. 

a. Encontrar los nombres de todos los empleados que 
tienen un hijo cuyo cumpleaños cae en marzo. 

b. Encontrar aquellos empleados que se examinaron 
del tipo de materia «mecanografía» en la ciudad 
«Madrid». 

c. Listar todos los tipos de materias en Emp. 

10.5 Escríbanse las consultas en XSLT y XPath sobre la 
DTD del Ejercicio 10.3 para listar todos los tipos de 
materia en Emp. 

10.6 Escríbase una consulta en XQuery en la representa¬ 
ción XML de la Figura 10.1 para encontrar el saldo 
total en cada sucursal a partir de todas las cuentas. 
(Consejo: se puede usar una consulta anidada para con¬ 
seguir el efecto de group by de SQL). 

10.7 Escríbase una consulta en XQuery en la representa¬ 
ción XML de la Figura 10.1 para calcular la reunión 
externa por la izquierda de los elementos impositor 
con los elementos cuenta. (Consejo: se puede usar la 
cuantificación universal.) 

10.8 Dese una consulta en XQuery para invertir el anida- 
rniento de los datos del Ejercicio 10.2. Esto es, el nivel 
más extemo del anidamiento de la salida debe tener los 
elementos correspondientes a los autores, y cada uno 
de estos elementos debe tener anidados los elementos 
correspondientes a todos los libros escritos por el autor. 

10.9 Dese la DTD para una representación XML de la infor¬ 
mación de la Figura 2.29. Créese un tipo de elemento 
separado para representar cada relación, pero úsense 
ID e IDREF para implementar las claves primarias y 
extemas. 

10.10 Escríbanse consultas en XSLT y XQuery que devuel¬ 
van los elementos cliente con los elementos cuenta 


asociados anidados en los elementos cliente, dada la 
representación de la información bancaria usando ID 
e IDREFS de la Figura 10.8. 

10.11 Dese un esquema relacional para representar la infor¬ 
mación bibliográfica como se especifica en el frag¬ 
mento DTD en la Figura 10.13. El esquema relacio¬ 
nal debe registrar el orden de los elementos autor. Se 
puede asumir que sólo los libros y artículos aparecen 
como elementos de nivel superior en los documentos 
XML. 

10.12 Considérese el Ejercicio 10.11 y supóngase que los 
autores también pueden aparecer como elementos de 
nivel superior ¿Qué cambio habría que realizar en el 
esquema relacional? 

10.13 Escríbanse las consultas en XQuery del fragmento 
DTD de bibliografía de la Figura 10.13 para realizar 
lo siguiente: 

a. Encontrar todos los autores que tienen un libro y 
un artículo en el mismo año. 

b. Mostrar los libros y artículos ordenados por años. 

c. Mostrar los libros con más de un autor. 

10.14 Mostrar la representación en árbol de los datos XML 
de la Figura 10.1 y la representación del árbol usando 
relaciones nodos e hijo descritas en el Apartado 10.6.1. 

10.15 Considérese la siguiente DTD recursiva 
<!DOCTYPE producto [ 

<!ELEMENT producto (nombre, ¡nfocomponen- 
te*)> 

<!ELEMENT infocomponente (producto, cantidad)> 
dELEMENT nombre ( #PCDATA )> 
dELEMENT cantidad ( #PCDATA )> 

]> 

a. Dese un pequeño ejemplo de datos correspondien¬ 
tes a la DTD de arriba. 

b. Muéstrese cómo hacer corresponder este DTD con 
un esquema relacional. Se puede asumir que los 
nombres de producto son únicos, esto es, cada vez 
que aparezca un producto, su estructura de com¬ 
ponente será la misma. 


cIDOCTYPE bibliografía [ 

<!ELEMENT libro (título, autor+, año, editor, lugar?)> 
<!ELEMENT artículo (título, autor+, revista, año, número, 
volumen, páginas?)> 

<!ELEMENT autor (apellidos, nombre) > 

<!ELEMENT título ( #PCDATA )> 

■■■ declaraciones PCDATA similares para año, editor, lugar, 
revista, año, número, volumen, páginas, apellidos y 
nombre 

]> 

FIGURA 10.13. DTD para los datos bibliográficos. 
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NOTAS BIBLIOGRÁFICAS 


El sitio XML Cover Pages (www.oasis-open.org/cover/) 
contiene una serie de información XML, incluyendo 
introducciones a XML, estándares, publicaciones y soft¬ 
ware. El consorcio W3C (World Wide Web Consortium) 
actúa como el cuerpo de normas para normas relacio¬ 
nadas con la Web, incluyendo XML básico y todos los 
lenguajes relacionados con XML tales como XPath, 
XSLT y XQuery. Hay disponibles en www.w3c.org un 
gran número de informes técnicos que definen los están¬ 
dares relacionados con XML. 

Lemández et al. [2000] proporcionan un álgebra para 
XML. Quilt se describe en Chamberlin et al. [2000]. 
Sahuguet [2001] describe un sistema basado en el len¬ 
guaje Quilt para consultas XML. Deutsch et al. [1999b] 
describen el lenguaje XML-QL. La integración de con¬ 
sultas de palabras clave en XML se describe en Llores- 
cu et al. [2000]. La optimización de consultas para XML 


se describe en McHugh y Widom [1999]. Lernández y 
Morishima [2001] describen una evaluación eficiente 
de consultas XML en sistemas middleware. Otro traba¬ 
jo sobre la consulta y manipulación de datos XML está 
en Chawathe [1999], Deutsch et al. [1999a] y Shan- 
mugasundaram et al. [2000]. 

Llorescu y Kossmann [1999], Kanne y Moerkotte 
[2000], y Shanmugasun-daram et al. [1999] describen 
el almacenamiento de datos XML. Schning [2001] des¬ 
cribe una base de datos diseñada para XML. El sopor¬ 
te de XML para bases de datos comerciales está des¬ 
crito en Banerjee et al. [2000], Cheng y Xu [2000], y 
Rys [2001]. Véanse los Capítulos 25 a 27 para más infor¬ 
mación sobre el soporte XML en bases de datos comer¬ 
ciales. El uso de XML para la integración de datos se 
describe en Liu et al. [2000], Draper et al. [2001], Baru 
et al. [1999], y Carey et al. [2000]. 


HERRAMIENTAS 


Hay disponibles una serie de herramientas de uso públi¬ 
co para tratar con XML. El sitio www.oasis-open.org/ 
cover/ contiene enlaces a una serie de herramientas soft¬ 
ware para XML y XSL (incluyendo XSLT). Kweelt (dis¬ 


ponible en http://db.cis.upenn.edu/Kweelt/) es un sis 
tema de consulta XML disponible públicamente basa 
do en el lenguaje Quilt. 
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PARTE 


IV 


ALMACENAMIENTO 
DE DATOS Y CONSULTAS 


A unque los sistemas de bases de datos proporcionan una visión de alto 
nivel de los datos, al final los datos se tienen que almacenar como bits 
en uno o varios dispositivos de almacenamiento. Una amplia mayoría 
de las bases de datos de hoy en día almacenan los datos en discos magnéticos 
y los extraen a la memoria del espacio principal para su procesamiento, o copian 
los datos en cintas y otros dispositivos de copia de seguridad para su almace¬ 
namiento en archivos. Las características físicas de los dispositivos de almace¬ 
namiento desempeñan un papel importante en el modo en que se almacenan 
los datos, en especial porque el acceso a un fragmento aleatorio de los datos 
en el disco resulta mucho más lento que el acceso a la memoria: los accesos al 
disco tardan decenas de milisegundos, mientras que el acceso a la memoria 
tarda una décima de microsegundo. 

El Capítulo 11 comienza con una introducción a los medios físicos de almace¬ 
namiento, incluidos los mecanismos para minimizar la posibilidad de pérdidas de 
datos debidas a fallos. El capítulo describe a continuación el modo en que se asig¬ 
nan los registros a los archivos que, a su vez, se asignan a bits del disco. El alma¬ 
cenamiento y la recuperación de los objetos se trata también en el Capítulo 11. 

Muchas consultas sólo hacen referencia a una pequeña parte de los registros 
de un archivo. Los índices son estructuras que ayudan a localizar rápidamente 
los registros deseados de una relación, sin examinar todos los registros. El índice 
de este libro de texto es un ejemplo, aunque, a diferencia de los índices de las 
bases de datos, está pensado para su empleo por personas. El Capítulo 12 des¬ 
cribe varios tipos de índices utilizados en los sistemas de bases de datos. 

Las consultas de los usuarios tienen que ejecutarse sobre el contenido de la 
base de datos, que reside en los dispositivos de almacenamiento. Suele resultar 
conveniente fraccionar las consultas en operaciones más pequeñas, que se corres¬ 
ponden aproximadamente con las operaciones del álgebra relacional. El Capí¬ 
tulo 13 describe el modo en que se procesan las consultas, presenta los algoritmos 
para la implementación de las operaciones individuales y esboza el modo en 
que las operaciones se ejecutan en sincronía para procesar una consulta. 

Hay muchas maneras alternativas de procesar cada consulta, que pueden 
tener costes muy variables. La optimización de consultas hace referencia al pro¬ 
ceso de hallar el método de coste mínimo para evaluar una consulta dada. El 
Capítulo 14 describe el proceso de optimización de consultas. 


CAPÍTULO 



ALMACENAMIENTO Y ESTRUCTURA 
DE ARCHIVOS 


E n los capítulos anteriores se han destacado los modelos de bases de datos de alto nivel. 
En el nivel conceptual o lógico se vieron las bases de datos, en el modelo relacional, 
como conjuntos de tablas. En realidad, el modelo lógico de las bases de datos es el nivel 
adecuado en el que se deben centrar los usuarios. Esto es por lo que el objetivo de un sistema 
de bases de datos es simplificar y facilitar el acceso a los datos; los usuarios del sistema no 
deben someterse sin necesidad alguna a la carga de los detalles físicos del desarrollo del sis¬ 
tema. 

En este capítulo, así como en los Capítulos 12, 13 y 14, se desciende desde los niveles supe¬ 
riores y se describen varios métodos para implementar los modelos de datos y los lenguajes 
presentados en los capítulos anteriores. Se comienza con las características de los medios de 
almacenamiento subyacentes, como los sistemas de discos y de cintas. Posteriormente se defi¬ 
nen varias estructuras de datos que permitirán un acceso rápido a los datos. Se estudian varias 
arquitecturas alternativas, cada una de ellas más adecuada a diferentes formas de acceder a los 
datos. La elección final de la estructura de datos hay que hacerla en función del uso que se espe¬ 
ra dar al sistema y de las características de cada máquina concreta. 


11.1. VISIÓN GENERAL DE LOS MEDIOS FÍSICOS DE ALMACENAMIENTO 


En la mayor parte de los sistemas informáticos hay 
varios tipos de almacenamientos de datos. Estos medios 
de almacenamiento se clasifican según la velocidad con 
la que se puede acceder a los datos, por el coste de adqui¬ 
sición del medio por unidad de datos y por la fiabilidad 
del medio. Entre los medios disponibles habitualmen¬ 
te figuran: 

• Caché. Caché es la forma de almacenamiento más 
rápida y costosa. La memoria caché es pequeña; su 
uso lo gestiona el hardware del sistema informáti¬ 
co. No hay que preocuparse sobre la gestión del 
almacenamiento caché del sistema de bases de datos. 

• Memoria principal. El medio de almacenamien¬ 
to utilizado para operar con los datos disponibles 
es la memoria principal. Las instrucciones de la 
máquina de propósito general operan en la memo¬ 
ria principal. Aunque la memoria principal puede 
contener muchos megabites de datos, suele ser 
demasiado pequeña (o demasiado cara) para guar¬ 
dar toda la base de datos. El contenido de la memo¬ 
ria principal suele perderse si se produce un fallo 
del suministro eléctrico o una caída del sistema. 

• Memoria flash. También conocida como memoria 
sólo de lectura programable y borrable eléctrica¬ 
mente (Electrically Erascible Programmable Read- 
Only Memory, EEPROM), la memoria flash se dife¬ 
rencia de la memoria principal en que los datos 


pueden sobrevivir a los fallos del suministro eléc¬ 
trico. La lectura de los datos de la memoria flash 
tarda menos de cien nanosegundos (un nanose- 
gundo es 0,001 milisegundo), lo que resulta apro¬ 
ximadamente igual de rápido que la lectura de los 
datos de la memoria principal. Sin embargo, la 
escritura de los datos en la memoria flash resulta 
más complicada (los datos pueden escribirse una 
sola vez, lo que tarda de cuatro a diez microse- 
gundos, pero no se pueden sobrescribir de manera 
directa). Para sobreescribir la memoria que se ha 
escrito previamente hay que borrar simultáneamente 
todo un banco de memoria; entonces queda prepa¬ 
rado para volver a escribir en él. Un inconvenien¬ 
te de la memoria/fa.vñ es que sólo permite un núme¬ 
ro limitado de ciclos de borrado, que varía entre 
diez mil y un millón. La memoria flash se ha hecho 
popular como sustituía de los discos magnéticos 
para guardar pequeños volúmenes de datos (de cin¬ 
co a diez megabytes) en los sistemas informáticos 
de coste reducido que se incluyen en otros dispo¬ 
sitivos, como computadoras de bolsillo y en otros 
dispositivos electrónicos como cámaras digitales. 

• Almacenamiento en discos magnéticos. El prin¬ 
cipal medio de almacenamiento a largo plazo de 
datos en conexión es el disco magnético. General¬ 
mente se guarda en este tipo de discos toda la base 
de datos. Para tener acceso a los datos hay que tras- 
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laclarlos desde el disco a la memoria principal. Des¬ 
pués de realizar la operación hay que escribir en el 
disco los datos que se han modificado. 

El tamaño de los discos magnéticos actuales 
oscila entre unos pocos gigabytes y 80 gigabytes. 
Tanto el extremo superior como el inferior de este 
rango han ido creciendo a un ritmo del 50 por cien¬ 
to anual, y se pueden esperar discos de mucha 
mayor capacidad cada año. El almacenamiento en 
disco puede aguantar los fallos del suministro eléc¬ 
trico y caídas del sistema. Los dispositivos de 
almacenamiento en disco pueden fallar a veces y, 
en consecuencia, destruir los datos, pero tales 
fallos suelen producirse con mucha menos fre¬ 
cuencia que una caída del sistema. 

• Almacenamiento óptico. La forma más popular 
de almacenamiento óptico es el disco compacto 
(Compact Disk, CD), que puede almacenar alrede¬ 
dor de 640 megabytes de datos, y el disco de video 
digital (Digital Video Disk, DVD), que puede alma¬ 
cenar 4,7 u 8,5 gigabytes de datos por cada cara del 
disco (o hasta 17 gigabytes en un disco de doble 
cara). Los datos se almacenan en un disco por 
medios ópticos y se leen mediante un láser. Los dis¬ 
cos ópticos usados en los discos compactos de sólo 
lectura (CD-ROM) o en los discos de vídeo digital 
de sólo lectura (DVD-ROM) no se pueden escri¬ 
bir, pero se suministran con datos pregrabados. 

Hay versiones «grabar una vez» de los discos 
compactos (llamada CD-R) y de los discos de 
vídeo digital (llamada DVD-R), que se pueden 
escribir sólo una vez; estos disco también se deno¬ 
minan de escritura única y lectura múltiple (Wri- 
te-Once, Read-Only Memory, WORM). También 
hay versiones «escribir varias veces» de los dis¬ 
cos compactos (llamada CD-RW) y de los discos 
de vídeo digital (DVD-RW y DVD-RAM), que 
permiten escribir varias veces. Los discos com¬ 
pactos grabables son dispositivos de almacena¬ 
miento magnetoópticos que usan medios ópticos 
para leer datos codificados magnéticamente. Estos 
discos son útiles para el almacenamiento de archi¬ 
vos así como para la distribución de datos. 

Los cambiadores automáticos (jukebox ) con¬ 
tienen unas cuantas unidades y numerosos discos 
que pueden cargarse de manera automática en una 
de las unidades (mediante un brazo robotizado) a 
petición del usuario. 

• Almacenamiento en cinta. El almacenamiento en 
cinta se utiliza principalmente para copias de segu¬ 
ridad y datos de archivo. Aunque la cinta magné¬ 
tica es mucho más barata que los discos, el acceso 
a los datos resulta mucho más lento, ya que el acce¬ 
so a la cinta debe ser secuencial desde su comien¬ 
zo. Por este motivo, el almacenamiento se deno¬ 
mina almacenamiento de acceso secuencial. En 
cambio, el almacenamiento en disco se denomina 


almacenamiento de acceso directo porque es posi¬ 
ble leer datos desde cualquier ubicación del disco. 

Las cintas tienen una capacidad elevada (actual¬ 
mente hay disponibles cintas de 40 a 300 gigaby¬ 
tes) y pueden retirarse de la unidad de lectura, lo 
que facilita un almacenamiento de coste reducido 
para archivos. Los cambiadores automáticos de 
cinta se utilizan para guardar conjuntos de datos 
excepcionalmente grandes, como los datos de sen¬ 
sores remotos de los satélites, que pueden alcan¬ 
zar cientos de terabytes (10 12 bytes) o incluso 
petabytes (10 15 bytes) de datos. 

Los diferentes medios de almacenamiento pueden 
organizarse en una jerarquía (Ligura 11.1) de acuerdo 
con su velocidad y su coste. Los niveles superiores son 
de coste elevado, pero rápidos. A medida que se des¬ 
ciende por la jerarquía el coste por bit disminuye, mien¬ 
tras que el tiempo de acceso aumenta. Este compromi¬ 
so es razonable; si un sistema de almacenamiento dado 
fuera a la vez más rápido y menos costoso que otro (sien¬ 
do iguales las demás propiedades) no habría ninguna 
razón para utilizar la memoria más lenta y más costosa. 
De hecho, muchos dispositivos de almacenamiento pri¬ 
mitivos, incluyendo la cinta de papel y las memorias de 
núcleos de ferrita, se hallan relegados a los museos aho¬ 
ra que la cinta magnética y la memoria de semiconduc¬ 
tores se han vuelto más rápidas y económicas. Las pro¬ 
pias cintas magnéticas se utilizaron para guardar los 
datos activos cuando los discos resultaban costosos y 
tenían una capacidad de almacenamiento reducida. Hoy 
en día casi todos los datos activos se almacenan en dis¬ 
cos, excepto en los raros casos en que se guardan en 
cambiadores automáticos de cinta u ópticos. 

Los medios de almacenamiento más rápidos (por 
ejemplo, caché y memoria principal) se denominan 
almacenamiento primario. Los medios del siguiente 



FIGURA 11.1. Jerarquía de dispositivos de almacena¬ 
miento. 
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nivel de la jerarquía (por ejemplo, los discos magnéti¬ 
cos) se conocen como almacenamiento secundario o 
almacenamiento en conexión. Los medios del nivel 
inferior de la jerarquía —por ejemplo, cinta magnética 
y los cambiadores automáticos de discos ópticos— se 
denominan almacenamiento terciario o almacena¬ 
miento sin conexión. 

Además de la velocidad y del coste de los diferen¬ 
tes sistemas de almacenamiento está también el asunto 
de la volatilidad del almacenamiento. El almacena¬ 


miento volátil pierde su contenido cuando se suprime 
el suministro eléctrico del dispositivo. En la jerarquía 
mostrada en la Figura 11.1 los sistemas de almacena¬ 
miento desde la memoria principal hacia arriba son volá¬ 
tiles, mientras que los sistemas de almacenamiento por 
debajo de la memoria principal son no volátiles. En 
ausencia de los costosos sistemas de baterías y de sis¬ 
temas de generadores de reserva, los datos deben escri¬ 
birse en almacenamiento no volátil por razones de 
seguridad. Se volverá a este asunto en el Capítulo 17. 


11.2. DISCOS MAGNÉTICOS 


Los discos magnéticos constituyen el principal medio 
de almacenamiento secundario en los sistemas infor¬ 
máticos modernos. Las capacidades de los discos han 
estado creciendo alrededor del 50 por ciento anual, pero 
los requisitos de las grandes aplicaciones también han 
estado creciendo muy rápido, en algunos casos más que 
la tasa de crecimiento de las capacidades de los discos. 
Una base de datos comercial grande típica puede nece¬ 
sitar centenares de discos. 

11.2.1. Características físicas de los discos 

Físicamente, los discos son relativamente sencillos 
(Figura 11.2). Cada plato del disco tiene una forma 
circular plana. Sus dos superficies están cubiertas por 
un material magnético y la información se graba en 
ellas. Los platos están hechos de metal rígido o de 
vidrio y están cubiertos (generalmente por los dos 
lados) con material magnético para grabaciones. Estos 
discos magnéticos se denominan discos rígidos para 



FIGURA 11.2. Mecanismo de disco de cabezas móviles. 


distinguirlos de los disquetes, que están hechos de 
material flexible. 

Mientras se está utilizando el disco, un motor lo hace 
girar a una velocidad constante elevada (generalmente 
60, 90 o 120 revoluciones por segundo, pero también 
hay disponibles discos girando a 250 revoluciones por 
segundo). Hay una cabeza de lectura y escritura ubica¬ 
da justo encima de la superficie del plato. La superficie 
del disco se divide a efectos lógicos en pistas, que se 
subdividen en sectores. Un sector es la unidad mínima 
de información que puede leerse o escribirse en el disco. 
En los discos disponibles actualmente, los tamaños de 
sector son normalmente de 512 bytes; hay alrededor 
de 16.000 pistas en cada disco y de dos a cuatro platos 
por disco. Las pistas internas (más cercanas al eje) son 
de menor longitud, y en los disco de la generación actual, 
las pistas exteriores contienen más sectores que las pis¬ 
tas intemas; normalmente hay alrededor de 200 secto¬ 
res por pista en las pistas internas y alrededor de 400 
sectores por pistas en las pistas extemas. Estos núme¬ 
ros pueden variar entre diferentes modelos; los mode¬ 
los de mayor capacidad tienen más sectores por pista y 
más pistas en cada plato. 

La cabeza de lectura y escritura guarda magnéti¬ 
camente la información en los sectores en forma de 
inversiones de la dirección de magnetización del mate¬ 
rial magnético. 

Cada cara de un plato del disco tiene una cabeza de 
lectura y escritura que se desplaza por el plato para tener 
acceso a las diferentes pistas. Un disco suele contener 
muchos platos y las cabezas de lectura y escritura de 
todas las pistas están montadas en un solo dispositivo 
denominado brazo del disco y se desplazan conjunta¬ 
mente. El conjunto de los platos del disco montados 
sobre un eje y las cabezas montadas en el brazo del dis¬ 
co se denomina dispositivo cabeza-disco. Dado que las 
cabezas de todos las platos se desplazan conjuntamen¬ 
te, cuando la cabeza de un plato se halle en la pista i- 
ésima, las cabezas de todos las demás platos también se 
encontrarán en la pista í-ésima de sus platos respecti¬ 
vos. Por consiguiente, las pistas í-ésimas de todos los 
platos se denominan conjuntamente cilindro í-ésimo. 
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Actualmente, los discos con un diámetro de plato de 
3 V 2 pulgadas dominan el mercado. Tienen un menor 
coste y tiempos de búsqueda más cortos (debido a las 
menores distancias de búsqueda) que los discos de tama¬ 
ño mayor (de hasta 14 pulgadas) que fueron habituales 
en el pasado, y proporcionan una alta capacidad de 
almacenamiento. 

Las cabezas de lectura y escritura se mantienen tan 
próximas como sea posible a la superficie de los dis¬ 
cos para aumentar la densidad de grabación. A menu¬ 
do la cabeza flota o vuela a sólo mieras de la superfi¬ 
cie del disco; las revoluciones del disco crean una 
pequeña brisa y el dispositivo de cabezas se manufac¬ 
tura de forma que la brisa mantenga la cabeza flotan¬ 
do sobre la superficie del disco. Como la cabeza flota 
tan cercana a la superficie, los platos deben estar ela¬ 
borados esmeradamente para que sean lisos. Los cho¬ 
ques de las cabezas pueden suponer un problema. Si la 
cabeza contacta con la superficie del disco, arrancará 
del disco el medio de grabación, destruyendo los datos 
que hubiera allí. Generalmente, la cabeza que toca la 
superficie hace que el material arrancado flote en el aire 
y se coloque entre las cabezas y sus platos, lo que cau¬ 
sa más choques. En circunstancias normales un choque 
de las cabezas da lugar a que falle todo el disco y haya 
que sustituirlo. Los dispositivos de disco de la genera¬ 
ción actual usan una fina capa de metal magnético como 
medio de grabación. Son menos susceptibles de fallar 
a causa de choques de las cabezas que los antiguos dis¬ 
cos cubiertos de óxido. 

Un disco de cabezas fijas tiene una cabeza diferen¬ 
te para cada pista. Esta disposición permite a la com¬ 
putadora cambiar rápidamente de pista a pista sin tener 
que desplazar el dispositivo de las cabezas, pero nece¬ 
sita gran número de cabezas, lo que hace al dispositivo 
excesivamente costoso. Algunos sistemas de discos tie¬ 
nen varios brazos de disco, lo que permite que se tenga 
acceso simultáneamente a más de una pista del mismo 
plato. Los discos de cabezas fijas y los discos con varios 
brazos se utilizaban en grandes sistemas de alto rendi¬ 
miento, pero ya no se fabrican. 

Un controlador de disco actúa como interfaz entre 
el sistema informático y el hardware concreto de la uni¬ 
dad de disco. Acepta las órdenes de alto nivel para leer 


o escribir en un sector e inicia las acciones, como des¬ 
plazar el brazo del disco a la pista adecuada y leer o 
escribir realmente los datos. Los controladores de dis¬ 
co también añaden comprobación de suma a cada sec¬ 
tor en el que se escribe; la comprobación de suma se 
calcula a partir de los datos escritos en el sector. Cuan¬ 
do se vuelve a leer el sector, se vuelve a calcular la suma 
a partir de los datos recuperados y se compara con la 
suma de comprobación guardada; si los datos se han 
deteriorado resulta muy probable que la suma de com¬ 
probación recién calculada no coincida con la guarda¬ 
da. Si se produce un error de este tipo, el controlador 
volverá a intentar varias veces la lectura; si el error sigue 
produciéndose, el controlador indicará un fallo de lec¬ 
tura. 

Otra labor interesante llevada a cabo por los contro¬ 
ladores de disco es la reasignación de los sectores 
dañados. Si el controlador detecta que un sector está 
dañado cuando se da formato al disco por primera vez, 
o cuando se realiza un intento de escribir en el sector, 
puede reasignar lógicamente el sector a una ubicación 
física diferente (escogida de entre un grupo de sectores 
extra preparado con esta finalidad). La reasignación se 
anota en disco o en memoria no volátil y la escritura 
se realiza en la nueva ubicación. 

En la Figura 11.3 se muestra la manera en que los 
discos se conectan a un sistema informático. Al igual 
que otras unidades de almacenamiento, los discos se 
conectan a un sistema informático o a un controlador 
mediante una conexión de alta velocidad. En los siste¬ 
mas de disco modernos, las funciones de menor nivel 
del controlador de disco, como el control del brazo, el 
cálculo y verificación de la comprobación de suma y la 
reasignación de los sectores dañados se implementan 
en la unidad de disco. 

La interfaz ATA (AT Attachment) (que es una ver¬ 
sión más rápida que la interfaz electrónica de dispo¬ 
sitivos integrados [IDE, Integrated Drive Electronics] 
usada antiguamente en los PC de IBM) y la interfaz de 
conexión para sistemas informáticos pequeños (SCSI, 
Small Computer-System Interconnect Interface, pro¬ 
nunciado «escasi») se usan habitualmente para conec¬ 
tar los discos con las computadoras personales y las 
estaciones de trabajo. Los grandes sistemas y los siste- 



FIGURA11.3. Subsistema de disco. 
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mas servidores suelen disponer de una interfaz más rápi¬ 
da y cara, como las versiones de alta capacidad de la 
interfaz SCSI, y la interfaz Fibre Channel. 

Los discos se conectan por lo general directamente 
al controlador de disco mediante cables, pero también 
pueden estar situados en una ubicación remota y estar 
conectados mediante una red de alta velocidad al con¬ 
trolador de disco. En una arquitectura de red de área 
de almacenamiento (Storage-Area NetWork, SAN), se 
conecta un gran número de discos mediante una red de 
alta velocidad a varias computadoras servidoras. Los 
discos generalmente se organizan localmente usando 
una técnica de organización del almacenamiento deno¬ 
minada «disposición redundante de discos indepen¬ 
dientes (Redundant Array of Independent Disks, RAID)» 
(descritos posteriormente en el Apartado 11.3) para dar 
a los servidores una vista lógica de un disco de gran 
tamaño y muy fiable. El controlador y el disco usan las 
interfaces SCSI y Fibre Channel para comunicarse entre 
sí, aunque puedan estar separados por una red. El acce¬ 
so remoto a los discos también significa que los discos 
que contienen datos importantes se pueden guardar en 
una habitación del servidor central donde se pueden 
supervisar y mantener por los administradores del sis¬ 
tema, en lugar de estar esparcidos en diferentes lugares 
de la organización. 

11.2.2. Medidas del rendimiento de los discos 

Las principales medidas de la calidad de un disco son 
la capacidad, el tiempo de acceso, la velocidad de trans¬ 
ferencia de datos y la fiabilidad. 

El tiempo de acceso es el tiempo transcurrido des¬ 
de que se formula una solicitud de lectura o de escritu¬ 
ra hasta que comienza la transferencia de datos. Para 
tener acceso (es decir, para leer o escribir) a los datos 
en un sector dado del disco, primero se debe desplazar 
el brazo para que se ubique sobre la pista correcta y lue¬ 
go hay que esperar a que el sector aparezca bajo el bra¬ 
zo por acción de la rotación del disco. El tiempo para 
volver a ubicar el brazo se denomina tiempo de bús¬ 
queda y aumenta con la distancia que deba recorrer el 
brazo. Los tiempos de búsqueda típicos varían de dos a 
treinta milisegundos, en función de la distancia de la 
pista a la posición inicial del brazo. Los discos de menor 
tamaño tienden a tener tiempos de búsqueda menores, 
dado que la cabeza tiene que recorrer una distancia 
menor. 

El tiempo medio de búsqueda es la media de los 
tiempos de búsqueda medido en una sucesión de soli¬ 
citudes aleatorias (uniformemente distribuidas). Si todas 
las pistas tienen el mismo número de sectores y des¬ 
preciando el tiempo requerido para que la cabeza ini¬ 
cie su movimiento y lo detenga, se puede demostrar 
que el tiempo medio de búsqueda es un tercio del peor 
de los tiempos de búsqueda posibles. Teniendo en cuen¬ 
ta estos factores, el tiempo medio de búsqueda es alre¬ 
dedor de la mitad del tiempo máximo de búsqueda. Los 


tiempos medios de búsqueda varían actualmente entre 
cuatro y diez milisegundos, dependiendo del modelo 
de disco. 

Una vez ha tenido lugar la búsqueda, el tiempo que 
se pasa esperando a que el sector al que hay que tener 
acceso aparezca bajo la cabeza se denomina tiempo de 
latencia rotacional. Las velocidades rotacionales típi¬ 
cas de los discos actuales varían de 5.400 rotaciones por 
minuto (90 rotaciones por segundo) hasta 15.000 rota¬ 
ciones por minuto (250 rotaciones por segundo) o, lo 
que es lo mismo, de 4 a 11,1 milisegundos por rotación. 
En media hace falta la mitad de una rotación del disco 
para que aparezca bajo la cabeza el comienzo del sec¬ 
tor deseado. Por tanto, el tiempo de latencia medio del 
disco es la mitad del tiempo empleado en una rotación 
completa del disco. 

El tiempo de acceso es la suma del tiempo de bús¬ 
queda y del tiempo de latencia y varía de 8 a 20 mili- 
segundos. Una vez que se ha ubicado bajo la cabeza el 
primer sector de datos, comienza su transferencia. La 
velocidad de transferencia de datos es la velocidad a 
la que se pueden recuperar o guardar datos en el disco. 
Los sistemas de disco actuales anuncian que permiten 
velocidades máximas de transferencia de 25 a 40 
megabytes por segundo, aunque las velocidades de trans¬ 
ferencia reales pueden ser significativamente menores, 
alrededor de 4 a 8 megabytes por segundo. 

La última de las medidas de los discos utilizadas con 
frecuencia es el tiempo medio entre fallos, que es una 
medida de la fiabilidad del disco. El tiempo medio entre 
fallos de un disco (o de cualquier otro sistema) es la can¬ 
tidad de tiempo que, en media, se puede esperar que el 
sistema funcione de manera continua sin tener ningún 
fallo. De acuerdo con los anuncios de los fabricantes, 
el tiempo medio entre fallos de los discos actuales varía 
de 30.000 a 1.200.000 horas (de 3,4 a 136 años). En la 
práctica, el tiempo medio entre fallos anunciado se cal¬ 
cula en términos de la probabilidad de fallo cuando el 
disco es nuevo (este escenario significa que dados 1.000 
discos relativamente nuevos, si el tiempo medio entre 
fallos es 1.200.000 horas, uno de ellos fallará en media 
en 1.200 horas). Un tiempo medio entre fallos de 
1.200.000 horas no implica que se espere que el disco 
vaya a funcionar 136 años. La mayoría de los discos tie¬ 
nen un periodo de vida esperado de cinco años, y tie¬ 
nen significativamente más fallos cuando son algunos 
años más viejos. 

Puede haber varios discos compartiendo una inter¬ 
faz de discos. La norma de la interfaz ATA-4 amplia¬ 
mente usada (también conocida como Ultra-DMA) 
soporta velocidades de transferencia de 33 megabytes 
por segundo, mientras que ATA-5 soporta 66 megaby¬ 
tes por segundo. SCSI-3 (Ultra 2 wide SCSI) soporta 
40 megabytes por segundo, mientras que la interfaz más 
cara Fibre Channel soporta hasta 256 megabytes por 
segundo. La velocidad de transferencia de la interfaz 
se comparte entre todos los discos conectados a la in¬ 
terfaz. 
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11.2.3. Optimización del acceso a los bloques 
del disco 

Las solicitudes de E/S al disco las generan tanto el sis¬ 
tema de archivos como el gestor de la memoria virtual 
que se halla en la mayor parte de los sistemas operati¬ 
vos. Cada solicitud especifica la dirección del disco a 
la que hay que hacer referencia; esa dirección está en la 
forma de un número de bloque. Un bloque es una 
secuencia continua de sectores de una sola pista de un 
plato. Los tamaños de los bloques varían de 512 bytes 
a varios kilobytes. Los datos se transfieren entre el dis¬ 
co y la memoria principal en unidades de bloques. Los 
niveles inferiores del gestor del sistema de archivos 
transforman las direcciones de los bloques en cilindro, 
superficie y número de sector del nivel de hardware. 

Dado que el acceso a los datos del disco es varios 
órdenes de magnitud más lento que el acceso a la memo¬ 
ria principal, se ha prestado mucha atención a la mejo¬ 
ra de la velocidad de acceso a los bloques del disco. La 
utilización de memoria intermedia para bloques en la 
memoria para satisfacer las solicitudes futuras se discute 
en el Apartado 11.5. Aquí se discuten otras técnicas. 

• Planificación. Si hay que transferir varios bloques 
de un cilindro desde el disco a la memoria princi¬ 
pal puede que se logre disminuir el tiempo de acce¬ 
so solicitando los bloques en el orden en el que pasa¬ 
rán por debajo de las cabezas. Si los bloques 
deseados se hallan en cilindros diferentes resulta 
ventajoso solicitar los bloques en un orden que mini¬ 
mice el movimiento del brazo del disco. Los algo¬ 
ritmos de planificación del brazo del disco inten¬ 
tan ordenar el acceso a las pistas de manera que se 
aumente el número de accesos que puede proce¬ 
sarse. Un algoritmo utilizado con frecuencia es el 
algoritmo del ascensor, que funciona de manera 
parecida a muchos ascensores. Supóngase que, ini¬ 
cialmente, el brazo se desplaza desde la pista más 
interna hacia el exterior del disco. Bajo el control 
del algoritmo del ascensor, en cada pista para la que 
hay una solicitud de acceso el brazo se detiene, 
atiende las solicitudes para la pista y continúa des¬ 
plazándose hacia el exterior hasta que no queden 
solicitudes pendientes para las pistas más externas. 
En este punto el brazo cambia de dirección, se des¬ 
plaza hacia el interior y vuelve a detenerse en cada 
pista para las que haya solicitudes hasta alcanzar 
una pista en la que no haya solicitudes para pistas 
más cercanas al centro del disco. En ese momento 
cambia de dirección e inicia un nuevo ciclo. Los 
controladores de disco suelen realizar la labor de 
reordenar las solicitudes de lectura para mejorar el 
rendimiento, dado que conocen perfectamente la 
organización de los bloques del disco, la posición 
rotacional de los platos y la posición del brazo. 

• Organización de archivos. Para reducir el tiem¬ 
po de acceso a los bloques se pueden organizar los 


bloques del disco de una manera que se corres¬ 
ponda fielmente con la forma en que se espera tener 
acceso a los datos. Por ejemplo, si se espera tener 
acceso secuencial a un archivo, en teoría se debe¬ 
rían guardar secuencialmente en cilindros adya¬ 
centes todos los bloques del archivo. Los sistemas 
operativos más antiguos, como los sistemas ope¬ 
rativos de IBM para grandes sistemas proporcio¬ 
naban a los programadores un control detallado de 
la ubicación de los archivos, lo que permitía a los 
programadores reservar un conjunto de cilindros 
para guardar un archivo. Sin embargo, este con¬ 
trol supone una carga para el programador o el 
administrador del sistema que debe decidir, por 
ejemplo, los cilindros que ha de asignar a un archi¬ 
vo y puede exigir una reorganización costosa si se 
insertan o borran datos del archivo. 

Los sistemas operativos posteriores, como Unix 
y los sistemas operativos para computadoras per¬ 
sonales ocultan a los usuarios la organización del 
disco y gestionan la asignación de manera interna. 
Sin embargo, en el transcurso del tiempo, un archi¬ 
vo secuencial puede quedar fragmentado; es decir, 
sus bloques pueden quedar dispersos por el disco. 
Para reducir la fragmentación, el sistema puede 
hacer una copia de seguridad de los datos del dis¬ 
co y restaurar todo el disco. La operación de res¬ 
tauración vuelve a escribir de manera contigua (o 
casi) los bloques de cada archivo. Algunos siste¬ 
mas (como MS-DOS) disponen de utilidades que 
examinan el disco y luego desplazan los bloques 
para reducir la fragmentación. Los aumentos de 
rendimiento obtenidos con estas técnicas pueden 
ser elevados, pero no se suele poder utilizar el sis¬ 
tema mientras se están ejecutando estas utilidades. 

• Memoria intermedia de escritura no volátil. 

Dado que el contenido de la memoria se pierde 
durante los fallos de suministro eléctrico, hay que 
guardar en disco la información sobre las actuali¬ 
zaciones de las bases de datos para que superen las 
posibles caídas del sistema. Por tanto, el rendi¬ 
miento de las aplicaciones de bases de datos sen¬ 
sibles a las actualizaciones, como los sistemas de 
procesamiento de transacciones, dependen mucho 
de la velocidad de escritura en el disco. 

Se puede utilizar memoria no volátil de acce¬ 
so aleatorio (RAM no volátil) para acelerar la 
escritura en el disco de manera drástica. El conte¬ 
nido de la RAM no volátil no se pierde durante un 
fallo del suministro eléctrico. Una manera habi¬ 
tual de implementar la RAM no volátil es utilizar 
RAM alimentada por baterías. La idea es que, 
cuando el sistema de bases de datos (o el sistema 
operativo) solicita que se escriba un bloque en el 
disco, el controlador del disco escriba el bloque en 
una memoria intermedia de RAM no volátil y 
comunique de manera inmediata al sistema ope- 
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rativo que la escritura se completó con éxito. El 
controlador escribe los datos en su destino en el 
disco en cualquier momento en que el disco no ten¬ 
ga otras solicitudes o cuando la memoria interme¬ 
dia de RAM no volátil se llene. Cuando el siste¬ 
ma de bases de datos solicita la escritura de un 
bloque sólo percibe un retraso si la memoria inter¬ 
media de RAM no volátil se encuentra llena. 
Durante la recuperación de una caída del sistema 
se vuelven a escribir en el disco todas las escritu¬ 
ras que se hallan pendientes en la memoria inter¬ 
media de RAM no volátil. 

El grado en el que la RAM no volátil aumenta el 
rendimiento se ilustra en el siguiente ejemplo. 
Supóngase que las solicitudes de escritura se reci¬ 
ben de manera aleatoria y que el disco se halla ocu¬ 
pado el 90 por ciento del tiempo como media 1 . Si 
se dispone de una memoria intermedia de RAM no 
volátil de cincuenta bloques, las solicitudes de escri¬ 
tura sólo encontrarán la memoria intermedia llena, 
en media, una vez por minuto (y tendrán, por tanto, 
que esperar a que concluya un proceso de escritura 
en el disco). Duplicar la memoria intermedia a cien 
bloques resulta en encontrar la memoria intermedia 
llena sólo una vez por hora. Por tanto, en la mayo¬ 
ría de los casos, las escrituras a disco se pueden eje¬ 
cutar sin que el sistema de bases de datos espere 
debido a una búsqueda o a la latencia rotacional. 

• Disco de registro histórico. Otro enfoque para 
reducir las latencias de escritura es utilizar un dis¬ 
co de registro histórico (de manera muy parecida 
a la memoria intermedia RAM no volátil). Todos 
los accesos al disco de registro histórico son secuen- 
ciales, lo que elimina principalmente el tiempo de 
búsqueda y, así, pueden escribirse simultáneamente 
varios bloques consecutivos, lo que hace que los 
procesos de escritura en el disco sean varias veces 


más rápidos que los procesos de escritura aleato¬ 
rios. Igual que ocurría anteriormente también hay 
que escribir los datos en su ubicación verdadera en 
el disco, pero este proceso de escritura puede lle¬ 
varse a cabo sin que el sistema de bases de datos 
tenga que esperar a que se complete. Más aún, el 
disco de registro histórico puede reordenar las escri¬ 
turas para reducir el movimiento del brazo. Si el 
sistema cae antes de que se hayan realizado algu¬ 
nas escrituras en la ubicación real del disco, cuan¬ 
do el sistema se recupere lee el disco de registro 
histórico para encontrar las escrituras que no se han 
realizado y entonces las completa. 

Los sistemas de archivo que soportan los dis¬ 
cos de registro histórico mencionados se denomi¬ 
nan sistemas de archivos de diario. Los sistemas 
de archivos de diario se pueden implementar inclu¬ 
so sin un disco de registro histórico aislado, guar¬ 
dando los datos y el registro histórico en el mis¬ 
mo disco. Al hacerlo así se reduce el coste 
económico a expensas de un menor rendimiento. 

El sistema de archivos basado en registro his¬ 
tórico es una versión extrema del enfoque del dis¬ 
co de registro histórico. Los datos no se vuelven a 
escribir en su ubicación original en el disco; en su 
lugar, el sistema de archivos hace un seguimiento 
del lugar del disco de registro histórico en que se 
escribieron los bloques más recientemente y los 
recupera desde esa ubicación. El propio disco de 
registro histórico se compacta de manera periódi¬ 
ca, por lo que se pueden eliminar los procesos de 
escritura antiguos que se han sobrescrito posterior¬ 
mente. Este enfoque mejora el rendimiento de los 
procesos de escritura pero genera un elevado gra¬ 
do de fragmentación de los archivos que se actua¬ 
lizan con frecuencia. Como se señaló anteriormen¬ 
te, esa fragmentación aumenta el tiempo de 
búsqueda en la lectura secuencial de los archivos. 


11.3. RAID 


Los requisitos de almacenamiento de datos de algunas 
aplicaciones (en particular las aplicaciones Web, de bases 
de datos y multimedia) han estado creciendo tan rápi¬ 
damente que se necesita un gran número de discos para 
almacenar sus datos, incluso aunque las capacidades de 
los discos hayan estado creciendo muy rápidamente. 

Tener un gran número de discos en un sistema pre¬ 
senta oportunidades para mejorar la velocidad a la que 
se pueden leer o escribir los datos si los discos funcio¬ 
nan en paralelo. El paralelismo se puede usar para rea¬ 
lizar varias lecturas o escrituras independientes simul¬ 

1 Para el lector interesado en la estadística se asume una distribución 
de Poisson para las llegadas. Las tasas exactas de llegada y de ser¬ 
vicio no se necesitan, dado que el uso del disco proporciona sufi¬ 
ciente información para estos cálculos. 


táneamente. Además, esta configuración ofrece la posi¬ 
bilidad de mejorar la fiabilidad del almacenamiento de 
datos, ya que se puede guardar información repetida en 
varios discos. Por tanto, el fallo de un disco no provo¬ 
ca una pérdida de datos. 

Para abordar los problemas de rendimiento y de fia¬ 
bilidad se han propuesto varias técnicas de organiza¬ 
ción de discos, denominadas colectivamente disposi¬ 
ción redundante de discos independientes (RAIDs - 
Redundant Array of Independent Disks), para con¬ 
seguir un rendimiento y fiabilidad mejorados. 
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En el pasado, los diseñadores de sistemas vieron los 
sistemas de almacenamiento compuestos de discos 
pequeños y de bajo coste como una alternativa econó¬ 
micamente efectiva a los discos grandes y caros; el cos¬ 
te por megabyte de los discos más pequeños era menor 
que el de los discos mayores. De hecho, la i de RAID, 
que ahora representa independientes , originalmente 
representaba económicos ( inexpensive ). Hoy en día, sin 
embargo, todos los discos son pequeños físicamente, y 
los discos de gran capacidad tienen realmente un menor 
coste por megabyte. Los sistemas RAID se usan por su 
mayor fiabilidad y por su mayor velocidad de transfe¬ 
rencia de datos, más que por motivos económicos. 

11.3.1. Mejora de la fiabilidad mediante 
la redundancia 

Considérese en primer lugar la fiabilidad. La posibili¬ 
dad de que algún disco de una disposición de N discos 
falle es mucho más elevada que la posibilidad de que 
un único disco concreto falle. Supóngase que el tiem¬ 
po medio entre fallos de un solo disco es de cien mil 
horas o, aproximadamente, once años. Por tanto, el tiem¬ 
po medio entre fallos de un disco de una disposición de 
cien discos será de 100.000/100 = 1.000 horas, o 42 
días, ¡lo que no es mucho! Si sólo se guarda una copia 
de los datos, cada fallo de un disco dará lugar a la pér¬ 
dida de una cantidad de datos significativa (como se dis¬ 
cutió anteriormente en el Apartado 11.2.1). Una tasa de 
pérdida de datos tan elevada resulta inaceptable. 

La solución al problema de la fiabilidad es introdu¬ 
cir la redundancia; es decir, se guarda información adi¬ 
cional que normalmente no se necesita pero que puede 
utilizarse en caso de fallo de un disco para reconstruir 
la información perdida. Por tanto, incluso si falla un dis¬ 
co, los datos no se pierden, por lo que el tiempo medio 
efectivo entre fallos aumenta, siempre que se cuenten 
sólo los fallos que den lugar a pérdida de datos o a su 
no disponibilidad. 

El enfoque más sencillo (pero el más costoso) para 
la introducción de la redundancia es duplicar todos los 
discos. Esta técnica se denomina creación de imáge¬ 
nes (o, a veces, creación de sombras). Un disco lógico 
consiste, por tanto, en dos discos físicos y cada proce¬ 
so de escritura se lleva a cabo en ambos discos. Si uno 
de los discos falla se pueden leer los datos del otro. Los 
datos sólo se perderán si falla el segundo disco antes de 
que se repare el primero que falló. 

El tiempo medio entre fallos (donde fallo es la pér¬ 
dida de datos) de un disco con imagen depende del tiem¬ 
po medio entre fallos de cada disco y del tiempo medio 
de reparación, que es el tiempo que se tarda (en media) 
en sustituir un disco averiado y en restaurar sus datos. 
Supóngase que los fallos de los dos discos son indepen¬ 
dientes ; es decir, no hay conexión entre el fallo de un 
disco y el del otro. Por tanto, si el tiempo medio entre 
fallos de un solo disco es de cien mil horas y el tiempo 
medio de reparación es de diez horas el tiempo medio 


entre pérdidas de datos de un sistema de discos con 
imagen es 100.000 2 /(2 x 10) = 500 x 10 6 horas, o ¡57.000 
años! (aquí no se entra en detalle en los cálculos; se pro¬ 
porcionan en las referencias de las notas bibliográficas). 

Hay que tener en cuenta que la suposición de la inde¬ 
pendencia de los fallos de los discos no resulta válida. 
Los fallos en el suministro eléctrico y los desastres natu¬ 
rales como los terremotos, los incendios y las inunda¬ 
ciones pueden dar lugar a daños simultáneos de ambos 
discos. A medida que los discos envejecen, la probabi¬ 
lidad de fallo aumenta, lo que aumenta la posibilidad 
de que falle el segundo disco mientras se repara el pri¬ 
mero. A pesar de todas estas consideraciones, sin embar¬ 
go, los sistemas de discos con imagen ofrecen una fia¬ 
bilidad mucho más elevada que los sistemas de discos 
únicos. Hoy en día están disponibles sistemas de discos 
con imagen con un tiempo medio entre pérdidas de datos 
de entre quinientas mil y un millón de horas, o de cin¬ 
cuenta y cinco a ciento diez años. 

Los fallos en el suministro eléctrico son una causa espe¬ 
cial de preocupación, dado que tienen lugar mucho más 
frecuentemente que los desastres naturales. Los fallos en 
el suministro eléctrico no son un problema si no se está 
realizando ninguna transferencia de datos al disco cuan¬ 
do tienen lugar. Sin embargo, incluso con la creación de 
imágenes de los discos, si los procesos de escritura se 
hallan en curso en el mismo bloque en ambos discos y el 
suministro eléctrico falla antes de que ambos bloques estén 
escritos completamente, los dos bloques pueden quedar 
en un estado inconsistente. La solución a este problema 
es escribir una copia en primer lugar y luego la otra, de 
modo que siempre sea consistente una de las copias. Hacen 
falta algunas acciones adicionales cuando se vuelve a ini¬ 
ciar el sistema después de un fallo en el suministro eléc¬ 
trico para recuperar los procesos de escritura incomple¬ 
tos. Este asunto se examina en el Ejercicio 11.4. 

11.3.2. Mejora del rendimiento mediante 
el paralelismo 

Considérense ahora las ventajas del acceso en paralelo 
a varios discos. Con la creación de imágenes de los dis¬ 
cos la velocidad a la que las solicitudes de lectura pue¬ 
den procesarse se duplica, dado que las solicitudes de 
lectura pueden enviarse a cualquiera de los discos (siem¬ 
pre y cuando los dos discos de la pareja estén operati¬ 
vos, como es el caso habitual). La velocidad de trans¬ 
ferencia de cada proceso de lectura es la misma que en 
los sistemas de discos únicos, pero el número de pro¬ 
cesos de lectura por unidad de tiempo se ha duplicado. 

Con varios discos también se puede mejorar la velo¬ 
cidad de transferencia distribuyendo los datos entre 
varios discos. En su forma más sencilla la distribución 
de datos consiste en dividir los bits de cada byte entre 
varios discos; esta distribución se denomina distribu¬ 
ción en el nivel de bit. Por ejemplo, si se dispone de 
una disposición de ocho discos se puede escribir el bit 
i de cada byte en el disco i. La disposición de ocho dis- 
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eos puede tratarse como un solo disco con sectores que 
tienen ocho veces el tamaño normal y, lo que es más 
importante, que tienen ocho veces la velocidad de acce¬ 
so. En una organización así cada disco toma parte en 
todos los accesos (de lectura o de escritura) por lo que 
el número de accesos que pueden procesarse por segun¬ 
do es aproximadamente el mismo que en un solo disco, 
pero cada acceso puede leer ocho veces tantos datos por 
unidad de tiempo como con un solo disco. La distribu¬ 
ción en el nivel de bit puede generalizarse a cualquier 
número de discos que sea múltiplo o divisor de ocho. 
Por ejemplo, si se utiliza una disposición de cuatro dis¬ 
cos, los bits i y 4 + i de cada byte irán al disco i. 

La distribución en el nivel de bloque reparte los blo¬ 
ques entre varios discos. Trata la disposición de discos 
como un único y gran disco, y proporciona números lógi¬ 
cos a los bloques; se asume que los números de bloque 
comienzan en 0. Con una disposición de n discos, la dis¬ 
tribución en el nivel de bloque asigna el bloque lógico i 
de la disposición de discos al disco (i mod n) + 1; usa el 
bloque físico [i/n\ - ésimo del disco para almacenar el 
bloque lógico i. Por ejemplo, con ocho discos, el bloque 
lógico 0 se almacena el bloque físico 0 del disco 1, mien¬ 
tras que el bloque lógico 11 se almacena en el bloque 
físico 1 del disco 4. Al leer un archivo grande, la distri¬ 
bución en el nivel de bloque busca n bloques en un ins¬ 
tante en paralelo en los n discos, dando una gran velo¬ 
cidad de transferencia para grandes lecturas. Cuando se 
lee un único bloque, la velocidad de transferencia de 
datos es igual que en un disco, pero los restantes n - 1 
discos están libres de realizar cualquier otra acción. 

La distribución en el nivel de bloque es la forma de 
distribución de datos más usada. También son posibles 
otros niveles de distribución, como los bytes de cada 
sector o los sectores de cada bloque. 

En resumen, hay dos objetivos principales para el 
paralelismo en un sistema de discos: 

Equilibrar la carga de varios accesos de pequeño 
tamaño (accesos a bloque) de manera que la producti¬ 
vidad de ese tipo de accesos aumente. 

Convertir en paralelos los accesos de gran tamaño 
para que su tiempo de respuesta se reduzca. 


se guardan cuatro discos de datos y los discos adicio¬ 
nales para guardar la información redundante para la 
recuperación en caso de fallo. 

• RAID de nivel 0 se refiere a disposiciones de dis¬ 
cos con distribución en el nivel de bloque pero sin 
redundancia (como la creación de imágenes o los 
bits de paridad). En la Figura 11.4a se muestra una 
disposición de tamaño cuatro. 

• RAID de nivel 1 se refiere a la creación de imá¬ 
genes del disco con distribución de bloques. En la 
Figura 11.4b se muestra una organización con ima¬ 
gen que tiene cuatro discos con datos. 

• RAID de nivel 2 también se conoce como organi¬ 
zación de códigos de corrección de errores tipo 
memoria ( memory-style error-correcting-code orga¬ 
nizarían, ECC). Los sistemas de memoria hace tiem¬ 
po que realizan la detección de errores utilizando los 
bits de paridad. Cada byte del sistema de memoria 
puede tener asociado un bit de paridad que registra 
si el número de bits del byte que valen uno es par 



(a) RAID 0: Distribución no redundante 



(b) RAID 1: Discos con imagen 



(c) RAID 2: Códigos de corrección de errores tipo memoria 



(d) RAID 3: Paridad con bits entrelazados 


11.3.3. Niveles de RAID 

La creación de imágenes proporciona gran fiabilidad 
pero resulta costosa. La distribución proporciona velo¬ 
cidades de transferencia de datos elevadas pero no mejo¬ 
ra la fiabilidad. Se han propuesto esquemas alternativos 
para proporcionar redundancia a bajo costo utilizando 
la idea de la distribución de los discos combinada con 
los bits de «paridad» (que se describen a continuación). 
Estos esquemas tienen diferentes compromisos entre el 
coste y el rendimiento. Los esquemas se clasifican en 
niveles denominados niveles de RAID, como se mues¬ 
tra en la Figura 11.4 (en la figura, P indica los bits para 
la corrección de errores y C indica una segunda copia 
de los datos). En todos los casos descritos en la figura 



(e) RAID 4: Paridad con bloques entrelazados 



(f) RAID 5: Paridad distribuida con bloques entrelazados 



FIGURA 11.4. Niveles de RAID. 
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(paridad = 0) o impar (paridad = 1). Si uno de los 
bits del byte se deteriora (un uno se transforma en 
cero o viceversa) la paridad del byte se modifica y, 
por tanto, no coincidirá con la paridad guardada. De 
manera parecida, si el bit de paridad guardado se 
deteriora no coincidirá con la paridad calculada. Por 
tanto, todos los errores de un bit son detectados por 
el sistema de memoria. Los esquemas de corrección 
de errores guardan dos o más bits adicionales y pue¬ 
den reconstruir los datos si se deteriora un solo bit. 

La idea de los códigos para la corrección de erro¬ 
res puede utilizarse directamente en los conjuntos 
de discos mediante la distribución de los bytes entre 
los discos. Por ejemplo, el primer bit de cada byte 
puede guardarse en el disco uno, el segundo en el 
disco dos, etcétera, hasta que se guarde el octavo 
bit en el disco ocho y los bits para la corrección de 
errores se guardan en los demás discos. 

Este esquema se muestra gráficamente en la 
Figura 11.4. Los discos marcados como P guardan 
los bits para la corrección de errores. Si uno de los 
discos falla, los bits restantes del byte y los bits 
para la corrección de errores asociados pueden leer¬ 
se de los demás discos y utilizarse para reconstruir 
los datos deteriorados. En la Figura 11.4c se mues¬ 
tra una disposición de tamaño cuatro; obsérvese 
que RAID de nivel 2 sólo necesita la sobrecarga 
de tres discos para cuatro discos de datos, a dife¬ 
rencia de R AID de nivel 1, que necesitaba la sobre¬ 
carga de cuatro discos. 

• RAID de nivel 3, u organización de paridad con 
bits entrelazados, mejora respecto al nivel 2 des¬ 
tacando que, a diferencia de los sistemas de memo¬ 
ria, los controladores de disco pueden detectar si 
un sector se ha leído correctamente, por lo que se 
puede utilizar un solo bit de paridad para la correc¬ 
ción y la detección de los errores. La idea es la 
siguiente. Si uno de los sectores se deteriora, se 
sabe exactamente el sector que es y para cada bit 
del mismo se puede determinar si es un uno o un 
cero calculando la paridad de los bits correspon¬ 
dientes a partir de los sectores de los demás dis¬ 
cos. Si la paridad de los bits restantes es igual que 
la paridad guardada, el bit ausente es un cero; en 
caso contrario, es un uno. 

RAID de nivel 3 es tan bueno como el nivel 2, 
pero resulta menos costoso en cuanto al número 
de discos adicionales (sólo tiene la sobrecarga de 
un disco), por lo que el nivel 2 no se utiliza en la 
práctica. Este esquema se muestra gráficamente en 
la Figura 11.4d. 

RAID de nivel 3 tiene dos ventajas respecto al 
nivel 1. Sólo se necesita un disco de paridad para 
varios discos normales, en comparación con un 
disco imagen por cada disco en el nivel 1, por lo 
que se reduce la sobrecarga de almacenamiento. 
Dado que los procesos de lectura y de escritura de 


un byte se extienden en varios discos, con la dis¬ 
tribución de datos en N vías, la velocidad de trans¬ 
ferencia es N veces tan rápida como con un solo 
disco. Por otro lado, RAID de nivel 3 permite un 
menor número de operaciones de E/S por segun¬ 
do, dado que todos los discos tienen que partici¬ 
par en cada solicitud de E/S. 

• RAID de nivel 4, u organización de paridad con 
bloques entrelazados, usa distribución de bloques, 
y además guarda un bloque de paridad en un dis¬ 
co aparte para los bloques correspondientes de los 
otros N discos. Este esquema se muestra gráfica¬ 
mente en la Figura 11.4e. Si uno de los discos falla 
puede utilizarse el bloque de paridad con los blo¬ 
ques correspondientes de los demás discos para 
restaurar los bloques del disco averiado. 

La lectura de un bloque sólo accede a un disco, 
lo que permite que los demás discos procesen otras 
solicitudes. Por tanto, la velocidad de transferen¬ 
cia de datos de cada acceso es menor, pero se pue¬ 
den ejecutar en paralelo varios accesos de lectura, 
lo que produce una mayor velocidad global de E/S. 
Las velocidades de transferencia para los procesos 
de lectura de gran tamaño son elevadas, dado que 
se pueden leer todos los discos en paralelo; los pro¬ 
cesos de escritura de gran tamaño también tienen 
velocidades de transferencia elevadas, dado que los 
datos y la paridad pueden escribirse en paralelo. 

Los procesos de escritura independientes de 
pequeño tamaño, por otro lado, no pueden reali¬ 
zarse en paralelo. La escritura de un bloque tiene 
que tener acceso al disco en el que se guarda ese 
bloque, así como al disco de paridad, dado que hay 
que actualizar el bloque de paridad. Además, hay 
que leer tanto el valor anterior del bloque de pari¬ 
dad como el del bloque que se escribe para calcu¬ 
lar la nueva paridad. Por tanto, un solo proceso de 
escritura necesita cuatro accesos a disco: dos para 
leer los dos bloques antiguos y otros dos para escri¬ 
bir los dos nuevos. 

• RAID de nivel 5, o paridad distribuida con bloques 
entrelazados, mejora respecto al nivel 4 dividiendo 
los datos y la paridad entre los N + 1 discos en vez 
de guardar los datos en N discos y la paridad en uno. 
En el nivel 5 todos los discos pueden participar en 
la atención a las solicitudes de lectura, a diferencia 
de RAID de nivel 4, en que el disco de paridad no 
puede participar, por lo que el nivel 5 aumenta el 
número total de solicitudes que pueden atenderse 
en una cantidad de tiempo dada. Para cada conjun¬ 
to de N bloques lógicos, uno de los discos guarda 
la paridad y los otros N guardan los bloques. 

Esta configuración se muestra gráficamente en 
la Figura 11.4f, en la que las P están distribuidas 
entre todos los discos. Por ejemplo, con una dispo¬ 
sición de cinco discos el bloque de paridad, mar¬ 
cado como Pk para los bloques lógicos 4 k, 4k+ 1, 
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4/i+2, 4/i+3 se guardan en el disco (k mod 5) + 1; 
los bloques correspondientes de los otros cuatro dis¬ 
cos guardan los cuatro bloques de datos 4k a 4k+3. 
La siguiente tabla muestra cómo se disponen los 
primeros veinte bloques, numerados de 0 a 19, y 
sus bloques de paridad. El patrón mostrado se repi¬ 
te para los siguientes bloques. 

Obsérvese que un bloque de paridad no puede 
guardar la paridad de los bloques del mismo dis¬ 
co, dado que entonces un fallo del disco supondría 
la pérdida de datos además de la de la paridad y, 
por tanto, no sería recuperable. El nivel 5 incluye 
al nivel 4, dado que ofrece mejor rendimiento de 
lectura y de escritura por el mismo coste, por lo 
que el nivel 4 no se utiliza en la práctica. 

• RATO de nivel 6, también denominado esquema de 
redundancia P+Q, es muy parecido a RAID de nivel 
5 pero guarda información redundante adicional 
para protección contra fallos de disco múltiples. En 
lugar de utilizar la paridad se utilizan códigos para 
la corrección de errores como los de Reed-Solomon 
(véanse las notas bibliográficas). En el esquema 
mostrado en la Figura 11.4g se guardan dos bits de 
datos redundantes por cada cuatro bits de datos (en 
comparación con un bit de paridad del nivel 5) y el 
sistema puede tolerar dos fallos del disco. 

Finalmente, se debe destacar que se han propuesto 
varias alternativas a los esquemas RAID básicos aquí 
descritos. 

Algunos fabricantes usan su propia terminología para 
describir sus implementaciones RAID 2 . Sin embargo, 
la terminología que se ha presentado es la más amplia¬ 
mente usada. 

11.3.4. Elección del nivel RAID adecuado 

Los factores a tener en cuenta al elegir un nivel RAID son: 

• Costo económico extra de los requisitos de alma¬ 
cenamiento en disco. 

• Requisitos de rendimiento en términos del núme¬ 
ro de operaciones E/S. 

• Rendimiento cuando falla un disco. 


• Rendimiento durante la reconstrucción (esto es, mien¬ 
tras los datos del disco averiado se reconstruyen en 
un nuevo disco). 

Si un disco falla, el tiempo que se tarda en recons¬ 
truir los datos que contenía puede ser significativo, y 
variará con el nivel RAID utilizado. La reconstrucción 
resulta más sencilla para RAID de nivel 1, dado que los 
datos pueden copiarse de otro disco; para los otros nive¬ 
les hay que tener acceso a todos los demás discos de la 
disposición para reconstruir los datos del disco averia¬ 
do. El rendimiento en la reconstrucción de un siste¬ 
ma RAID puede ser un factor importante si se necesita 
un aporte continuo de datos, como ocurre en los siste¬ 
mas de bases de datos de alto rendimiento. Además, 
dado que el tiempo de reconstrucción puede formar par¬ 
te del tiempo de reparación, el rendimiento de la recons¬ 
trucción influye en el tiempo medio entre fallos. 

RAI D de nivel 0 se usa en aplicaciones de alto rendi¬ 
miento donde la seguridad de los datos no es crítica. Dado 
que los niveles 2 y 4 de RAID se incluyen en los niveles 
3 y 5 de RAID, la elección de los niveles RAID se limi¬ 
ta a los niveles restantes. La distribución de bits (nivel 3) 
se usa raramente, dado que la distribución de bloques 
(nivel 5) da buenas velocidades de transferencia de datos 
para grandes transferencias. Para pequeñas transferen¬ 
cias, el tiempo de acceso a disco es el factor dominante, 
así que el beneficio de las lecturas paralelas disminuye. 
De hecho, el nivel 3 puede funcionar peor que el nivel 5 
para una pequeña transferencia, ya que la transferencia 
sólo se completa cuando los sectores correspondientes 
en todos los discos se hayan encontrado; la latencia media 
de la disposición de discos se comporta de forma muy 
parecida a la latencia en el caso peor para un único dis¬ 
co, descartando los beneficios de las mayores velocida¬ 
des de transferencia. El nivel 6 no se soporta actualmen¬ 
te en muchas implementaciones RAID, pero ofrece una 
mejor fiabilidad que el nivel 5 y se puede usar en aplica¬ 
ciones donde la seguridad de datos es muy importante. 

La elección entre RAID de nivel 1 y de nivel 5 es 
más difícil de tomar. RAID de nivel 1 es popular para 
las aplicaciones como el almacenamiento de archivos 
de registro histórico en un sistema de bases de datos, ya 
que ofrece el mejor rendimiento en escritura. RAID de 
nivel 5 tiene una menor sobrecarga de almacenamien¬ 
to que el nivel 1, pero tiene una mayor sobrecarga en 
las escrituras. Para las aplicaciones donde los datos se 
leen frecuentemente y se escriben raramente, el nivel 5 
es la elección adecuada. 

Las capacidades de almacenamiento en disco han 
estado aumentando a una velocidad sobre el 50 por 
ciento al año durante muchos años, y el costo por byte 


2 Por ejemplo, algunos productos usan el nivel 1 de RAID para refe¬ 
rirse a discos imagen sin distribución y el nivel 1 + 0 o 10 para los 
discos imagen con distribución. Esta distinción no es realmente nece¬ 
saria, ya que la no distribución se puede ver como un caso especial 
de distribución, en concreto, la distribución sobre un único disco. 
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ha estado decreciendo a la misma velocidad. Como 
resultado, para muchas aplicaciones existentes de 
bases de datos con requisitos moderados de almace¬ 
namiento, el costo económico del almacenamiento 
extra en disco necesario para la creación de imágenes 
ha sido relativamente pequeño (sin embargo, el costo 
económico extra, sigue siendo un aspecto significati¬ 
vo para las aplicaciones de almacenamiento intensivo 
como el almacenamiento de datos de vídeo). Las velo¬ 
cidades de acceso se han mejorado a una velocidad 
mucho menor (cerca de un factor 3 durante 10 años), 
mientras que el número de operaciones E/S requeri¬ 
das por segundo se han incrementado enormemente, 
particularmente en los servidores de aplicaciones Web. 

El nivel 5 de RAID, que incrementa el número de 
operaciones E/S necesarias para escribir un único blo¬ 
que lógico, sufre una penalización de tiempo significa¬ 
tiva en términos del rendimiento en escritura. El nivel 
1 de RAID es, por tanto, la elección adecuada para 
muchas aplicaciones con requisitos moderados de alma¬ 
cenamiento y altos requisitos de E/S. 

Los diseñadores de sistemas RAID tienen también 
que hacer otras decisiones. Por ejemplo, la cantidad de 
discos que habrá en la disposición y los bits que debe 
proteger cada bit de paridad. Si hay más discos en la 
disposición, las velocidades de transferencia de datos 
son mayores pero el sistema sería más caro. Si hay más 
bits protegidos por cada bit de paridad, la sobrecarga de 
espacio debida a los bits de paridad es menor, pero hay 
más posibilidades de que falle un segundo disco antes 
de que el primer disco en averiarse esté reparado y que 
eso dé lugar a la pérdida de datos. 

11.3.5. Aspectos hardware 

Otro aspecto en la elección de implementaciones RAID 
se encuentra en el nivel hardware. RAID se puede imple- 
mentar sin cambios en el nivel hardware modificando 
sólo el software. Tales implementaciones se conocen 
como RAID software. Sin embargo, hay beneficios sig¬ 
nificativos al construir hardware de propósito especial 
para dar soporte a RAID, que se describen a continua¬ 
ción; los sistemas con soporte hardware especial se 
denominan sistemas RAID hardware. 

Las implementaciones RAID hardware pueden usar 
RAM no volátil para registrar las escrituras que es nece¬ 
sario ejecutar; en caso de fallo de corriente antes de que 


se complete una escritura, el sistema se restaura recu¬ 
perando información acerca de las escrituras incom¬ 
pletas de la memoria RAM no volátil y entonces com¬ 
pleta las escrituras. Sin el soporte hardware, se necesita 
trabajo extra para detectar los bloques que se hayan 
escrito parcialmente antes del fallo de corriente (véase 
el Ejercicio 11.4). 

Algunas implementaciones RAID permiten el inter¬ 
cambio en caliente; esto es, los discos averiados se pue¬ 
den eliminar y reemplazar por otros nuevos sin desco¬ 
nectar la corriente. El intercambio en caliente reduce el 
tiempo medio de reparación, ya que el cambio de un 
disco no debe esperar hasta que se pueda apagar el sis¬ 
tema. De hecho, muchos sistemas críticos actuales se 
ejecutan con una planificación 24 x 7; esto es, se eje¬ 
cutan 24 horas al día y 7 días a la semana, sin propor¬ 
cionar ningún momento para apagar el sistema y cam¬ 
biar el disco averiado. Como resultado, el tiempo medio 
de reparación se reduce en gran medida, minimizando 
la posibilidad de pérdida de datos. El disco averiado se 
puede reemplazar en los ratos libres. 

La fuente de alimentación, o el controlador de disco, 
o incluso la interconexión del sistema en un sistema 
RAI D podría llegar a ser un punto de fallo que detendría 
el funcionamiento del sistema RAID. Para evitar esta 
posibilidad, las buenas implementaciones RAID tienen 
varias fuentes de alimentación (con baterías de respaldo 
que les permiten continuar funcionando aunque se cor¬ 
te la corriente). Tales sistemas RAID tienen varios con¬ 
troladores de disco y varias interconexiones para conec¬ 
tarlos con el sistema informático (o a la red de los 
sistemas informáticos). Así, el fallo de cualquier com¬ 
ponente no detendrá el funcionamiento del sistema RAID. 

11.3.6. Otras aplicaciones de RAID 

Los conceptos de RAID se han generalizado a otros dis¬ 
positivos de almacenamiento, incluyendo los conjuntos 
de cintas, e incluso a la transmisión de datos por siste¬ 
mas de radio. Cuando se aplican a los conjuntos de cin¬ 
tas, las estructuras RAID pueden recuperar datos aun¬ 
que se deteriore una de las cintas de la disposición. 
Cuando se aplican a la transmisión de datos, cada blo¬ 
que de datos se divide en unidades menores y se trans¬ 
mite junto con una unidad de paridad; si por algún moti¬ 
vo no se recibe alguna de las unidades, se puede 
reconstruir a partir del resto. 


11.4. ALMACENAMIENTO TERCIARIO 


En un sistema de bases de datos de gran tamaño puede 
que parte de los datos tenga que residir en almacena¬ 
miento terciario. Los dos medios de almacenamiento 
terciario más frecuentes son los discos ópticos y las cin¬ 
tas magnéticas. 


11.4.1. Discos ópticos 

Los discos compactos son un medio popular de distri¬ 
bución de software, datos multimedia como el sonido 
y las imágenes, y otra información editada de manera 
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electrónica. Tienen una elevada capacidad de almace¬ 
namiento (640 megabytes) y resulta barato producir 
masivamente los discos. 

Los discos de vídeo digital (DVD, Digital Video 
Disk) están reemplazando a los discos compactos en las 
aplicaciones que requieren grandes cantidades de datos. 
Los discos en formato DVD-5 pueden almacenar 4,7 
gigabytes de datos (en una superficie de grabación), 
mientras que los discos en formato DVD-9 pueden alma¬ 
cenar 8,5 gigabytes de datos (en dos superficies de dis¬ 
co). La grabación en ambas caras de un disco ofrece 
incluso mayores capacidades; los formatos DVD-10 y 
DVD-18, que son las versiones de doble cara de DVD- 
5 y DVD-9, pueden almacenar respectivamente 9,4 y 
17 gigabytes. 

Las unidades CD y DVD presentan tiempos de bús¬ 
queda mucho mayores (100 milisegundos es un valor 
frecuente) que las unidades de discos magnéticos, debi¬ 
do a que el dispositivo de cabezas es más pesado. Las 
velocidades rotacionales son generalmente menores, 
aunque las unidades CD y DVD más rápidas tienen velo¬ 
cidades rotacionales alrededor de 3.000 revoluciones 
por minuto, que son comparables a las velocidades de 
los discos magnéticos de gama baja. Las velocidades 
rotacionales se correspondían inicialmente con las nor¬ 
mas de los CD de sonido, y las velocidades de las uni¬ 
dades DVD se correspondían inicialmente con las nor¬ 
mas de los DVD de vídeo, pero hoy en día se dispone 
de unidades que hacen girar los discos muchas veces la 
velocidad normal. 

Las velocidades de transferencia de datos son algo 
menores que los discos magnéticos. Las unidades CD 
actuales leen entre 3 y 6 megabytes por segundo, y las 
unidades DVD actuales leen de 8 a 15 megabytes por 
segundo. Al igual que las unidades de discos magnéti¬ 
cos, los discos ópticos almacenan más datos en las pis¬ 
tas exteriores y menos en las interiores. La velocidad 
de transferencia de las unidades ópticas se caracteriza 
por nx, que significa que la unidad soporta transferen¬ 
cias n veces la velocidad normal; las velocidades 50x 
para CD y 12 x para DVD son comunes actualmente. 

Las versiones de escritura única de los discos ópti¬ 
cos (CD-R y DVD-R) son populares para la distribu¬ 
ción de datos y en particular para el almacenamiento de 
archivo de datos porque tienen una gran capacidad, un 
tiempo de vida mayor que los discos magnéticos y pue¬ 
den retirarse de la unidad y almacenarse en un lugar 
remoto. Dado que no pueden sobrescribirse, se pueden 
usar para almacenar información que no debería cam¬ 
biarse, como los rastros de auditoría. Las versiones de 
varias escrituras (CR-RW, DVD-RW y DVD-RAM) 
también se usan para archivo. 

Los cambiadores de discos son dispositivos que 
guardan un gran número de discos ópticos (hasta varios 
cientos) y los cargan automáticamente bajo demanda en 
una de las pocas unidades (usualmente entre una y diez). 
La capacidad de almacenamiento agregada de tal siste¬ 
ma puede tener muchos terabytes. Cuando se accede a 


un disco, se carga mediante un brazo mecánico desde 
una estantería en la unidad (cualquier disco que estu¬ 
viese previamente en la unidad se debe devolver a la 
estantería). El tiempo de carga y descarga suele ser del 
orden de segundos (mucho más lento que los tiempos 
de acceso a disco). 

11.4.2. Cintas magnéticas 

Aunque las cintas magnéticas son relativamente per¬ 
manentes y pueden albergar grandes volúmenes de 
datos, resultan lentas en comparación con los discos 
magnéticos y ópticos. Aún más importante, la cinta mag¬ 
nética está limitada al acceso secuencial. Por tanto, resul¬ 
ta inadecuada para proporcionar el acceso aleatorio que 
cumple la mayor parte de los requisitos del almacena¬ 
miento secundario, aunque históricamente, antes del uso 
de los discos magnéticos, las cintas se usaron como 
medio de almacenamiento secundario. 

Las cintas se utilizan principalmente para copias de 
seguridad, para el almacenamiento de la información 
poco utilizada y como medio sin conexión para trans¬ 
ferir información de un sistema a otro. Las cintas tam¬ 
bién se usan para almacenar grandes volúmenes de 
datos, tales como datos vídeo o de imagen que, o no es 
necesario acceder rápidamente a ellos o son tan volu¬ 
minosos que el almacenamiento en disco sería muy caro. 

Una cinta se guarda en una bobina y se enrolla o 
desenrolla sobre una cabeza de lectura y escritura. El 
desplazamiento hasta el punto correcto de la cinta pue¬ 
de tardar minutos en vez de milisegundos; una vez en 
posición, sin embargo, las unidades de cinta pueden 
escribir los datos con densidades y velocidades que se 
aproximan a las de las unidades de disco. Las capaci¬ 
dades varían en función de la longitud y de la anchura 
de la cinta y de la densidad con la que la cabeza pueda 
leer y escribir. El mercado está actualmente dividido en 
una amplia variedad de formatos de cinta. Las capaci¬ 
dades actuales disponibles varían de unos pocos gigaby¬ 
tes (con el formato DAT [Digital Audio Tape, cinta de 
audio digital]), 10 a 40 gigabytes (con el formato DLT 
[Digital Linear Tape, cinta lineal digital]), 100 gigaby¬ 
tes y aún más (con el formato Ultrium), hasta 330 
gigabytes (con los formatos de cinta de exploración 
helicoidal de Ampex). Las velocidades de transferen¬ 
cia de datos son del orden de algunos hasta decenas de 
megabytes por segundo. 

Las unidades de cinta son muy fiables y los buenos 
sistemas de unidades de cinta realizan la lectura de los 
datos recién escritos para asegurar que se han registra¬ 
do correctamente. Sin embargo, las cintas presentan 
límites en cuanto al número de veces que se pueden leer 
o escribir con fiabilidad. 

Algunos formatos de cinta (como el formato Acce- 
lis) soportan velocidades de búsqueda mayores (del 
orden de decenas de segundos), lo cual es importante 
para las aplicaciones que necesitan un rápido acceso a 
muy grandes cantidades de datos, mayores de lo que 
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económicamente podría caber en una unidad de disco. 
La mayoría del resto de formatos de cinta proporcionan 
mayores capacidades al precio de un acceso más lento; 
estos formatos son ideales para la copia de seguridad de 
datos, donde las búsquedas rápidas no son importantes. 

Los cambiadores de cintas, al igual que los cambia¬ 
dores de discos ópticos, guardan gran número de cintas 
con unas cuantas unidades en las que se pueden mon¬ 


tar las cintas; se utilizan para guardar grandes volúme¬ 
nes de datos, que pueden llegar a varios terabytes (10 12 
bytes) con tiempos de acceso del orden de segundos 
hasta unos cuantos minutos. Las aplicaciones que nece¬ 
sitan estos enormes almacenamientos de datos incluyen 
los sistemas de imágenes que reúnen los datos de los 
satélites de teledetección, y grandes bibliotecas de vídeo 
para las cadenas de televisión. 


11.5. ACCESO AL ALMACENAMIENTO 


Las bases de datos se corresponden con cierto número 
de archivos diferentes que mantiene el sistema operati¬ 
vo subyacente. Estos archivos residen permanentemente 
en los discos, con copias de seguridad en cinta. Cada 
archivo se divide en unidades de almacenamiento de 
longitud constante denominadas bloques, que son las 
unidades de asignación de almacenamiento y de trans¬ 
ferencia de datos. En el Apartado 11.6 se discutirán 
varias maneras de organizar los datos en archivos de 
manera lógica. 

Cada bloque puede contener varios elementos de datos. 
El conjunto concreto de elementos de datos que contie¬ 
ne cada bloque viene determinado por la forma de orga¬ 
nización física de los datos que se utilice (véase el Apar¬ 
tado 11.6). Se supondrá que ningún elemento de datos 
ocupa dos o más bloques. Esta suposición es realista para 
la mayor parte de las aplicaciones de procesamiento de 
datos, como el ejemplo bancario aquí propuesto. 

Uno de los principales objetivos del sistema de bases 
de datos es minimizar el número de transferencias de 
bloques entre el disco y la memoria. Una manera de 
reducir el número de accesos al disco es mantener en la 
memoria principal todos los bloques que sea posible. El 
objetivo es maximizar la posibilidad de que, cuando se 
tenga acceso a un bloque, ya se encuentre en la memo¬ 
ria principal y, por tanto, no se necesite realizar un acce¬ 
so al disco. 

Dado que no resulta posible mantener en la memo¬ 
ria principal todos los bloques hay que gestionar la asig¬ 
nación del espacio disponible en la memoria principal 
para el almacenamiento de los mismos. La memoria 
intermedia (buffer) es la parte de la memoria principal 
disponible para el almacenamiento de las copias de los 
bloques del disco. Siempre se guarda en el disco una 
copia de cada bloque, pero esta copia puede ser una 
versión del bloque más antigua que la versión de la 
memoria intermedia. El subsistema responsable de 
la asignación del espacio de la memoria intermedia se 
denomina gestor de la memoria intermedia. 

11.5.1. Gestor de la memoria intermedia 

Los programas de un sistema de bases de datos formu¬ 
lan solicitudes (es decir, llamadas) al gestor de la memo¬ 


ria intermedia cuando necesitan un bloque del disco. Si 
el bloque ya se encuentra en la memoria intermedia se 
pasa al solicitante la dirección del bloque en la memo¬ 
ria principal. Si el bloque no se halla en la memoria 
intermedia, el gestor de la memoria intermedia asigna 
en primer lugar espacio al bloque en la memoria inter¬ 
media, descartando algún otro bloque si hace falta para 
hacer sitio para el nuevo bloque. Sólo se vuelve a escri¬ 
bir en el disco el bloque que se descarta si se modificó 
desde la última vez que se escribió en el disco. A con¬ 
tinuación, el gestor de la memoria intermedia lee el blo¬ 
que del disco y lo escribe en la memoria intermedia, y 
pasa la dirección del bloque en la memoria principal al 
solicitante. Las acciones intemas del gestor de la memo¬ 
ria intermedia resultan transparentes para los progra¬ 
mas que formulan solicitudes de bloques de disco. 

Si se está familiarizado con los conceptos de los sis¬ 
temas operativos se observará que el gestor de la memo¬ 
ria intermedia no parece ser más que un gestor de la 
memoria virtual, como los que se hallan en la mayor 
parte de los sistemas operativos. Una diferencia estriba 
en que el tamaño de la base de datos puede ser mucho 
mayor que el espacio de direcciones de hardware de la 
máquina, por lo que las direcciones de memoria no resul¬ 
tan suficientes para direccionar todos los bloques de 
memoria. Además, para dar un buen servicio al sistema 
de bases de datos el gestor de la memoria intermedia 
debe utilizar técnicas más complejas que los esquemas 
de gestión de la memoria virtual habituales: 

• Estrategia de sustitución. Cuando no queda espa¬ 
cio libre en la memoria intermedia hay que elimi¬ 
nar un bloque de ésta antes de que se pueda escri¬ 
bir en él otro nuevo. Generalmente los sistemas 
operativos utilizan un esquema menos reciente¬ 
mente utilizado (Least Recently Used, LRU), en 
el que se vuelve a escribir en el disco y se elimina 
de la memoria intermedia el bloque al que se ha 
hecho referencia menos recientemente. 

• Bloques clavados. Para que el sistema de bases 
de datos pueda recuperarse de las caídas (Capítu¬ 
lo 17) resulta necesario limitar las ocasiones en 
que se puede volver a escribir el bloque en el dis- 
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co. Se dice que un bloque al que no se le permite 
que se vuelva a escribir en el disco está clavado. 
Aunque muchos sistemas operativos no permiten 
trabajar con bloques clavados, esta prestación resul¬ 
ta esencial para la implementación de un sistema 
de bases de datos resistente a las caídas. 

• Salida forzada de los bloques. Hay situaciones 
en las que resulta necesario volver a escribir el blo¬ 
que en el disco, aunque no se necesite el espacio 
de memoria intermedia que ocupa. Este proceso 
de escritura se denomina salida forzada del blo¬ 
que. Se verá el motivo de que se necesite la salida 
forzada en el Capítulo 17; para resumirlo, el con¬ 
tenido de la memoria principal y, por tanto, el de 
la memoria intermedia se pierde en las caídas, 
mientras que los datos del disco suelen sobrevivir 
a ellos. 

11.5.2. Políticas para la sustitución 
de la memoria intermedia 

El objetivo de las estrategias de sustitución de los blo¬ 
ques de la memoria intermedia es la minimización de 
los accesos al disco. En los programas de propósito gene¬ 
ral no resulta posible predecir con precisión los bloques 
a los que se hará referencia. Por tanto, los sistemas ope¬ 
rativos utilizan la pauta anterior de las referencias a los 
bloques como forma de predecir las referencias futuras. 
La suposición que suele hacerse es que es probable que 
se vuelva a hacer referencia a los bloques a los que se 
ha hecho referencia recientemente. Por tanto, si hay que 
sustituir un bloque, se sustituye el bloque al que se ha 
hecho referencia menos recientemente. Este enfoque se 
denomina esquema de sustitución de bloques LRU. 

LRU es un esquema de sustitución aceptable para los 
sistemas operativos. Sin embargo, los sistemas de bases 
de datos pueden predecir la pauta de las referencias futu¬ 
ras con más precisión que los sistemas operativos. Las 
peticiones del usuario al sistema de bases de datos com¬ 
prenden varias etapas. El sistema de bases de datos sue¬ 
le poder determinar con antelación los bloques que se 
necesitarán examinando cada una de las etapas necesa¬ 
rias para llevar a cabo la operación solicitada por el usua¬ 


rio. Por tanto, a diferencia de los sistemas operativos, 
que deben confiar en el pasado para predecir el futuro, 
los sistemas de bases de datos pueden tener información 
concerniente al menos al futuro a corto plazo. 

Para ilustrar la manera en que la información relati¬ 
va al futuro acceso a los bloques permite mejorar la estra¬ 
tegia LRU considérese el procesamiento de la expresión 
del álgebra relacional 

prestatario x cliente 

Supóngase que la estrategia escogida para procesar esta 
solicitud viene dada por el programa en seudocódigo 
mostrado en la Figura 11.5 (se estudiarán otras estrate¬ 
gias en el Capítulo 13). 

Supóngase que las dos relaciones de este ejemplo se 
guardan en archivos diferentes. En este ejemplo se pue¬ 
de ver que, una vez que se haya procesado la tupia de 
prestatario, no se vuelve a necesitar. Por tanto, una vez 
que se ha completado el procesamiento de un bloque 
completo de tupias de prestatario, ese bloque ya no se 
necesita en la memoria principal, aunque se haya utili¬ 
zado recientemente. Deben darse instrucciones al ges¬ 
tor de la memoria intermedia para liberar el espacio ocu¬ 
pado por el bloque de prestatario tan pronto como se 
haya procesado la última tupia. Esta estrategia de ges¬ 
tión de la memoria intermedia se denomina estrategia 
de extracción inmediata. 

Considérense ahora los bloques que contienen las 
tupias de cliente. Hay que examinar una vez cada blo¬ 
que de las tupias cliente por cada tupia de la relación 
prestatario. Cuando se completa el procesamiento del 
bloque cliente se sabe que no se tendrá nuevamente acce¬ 
so a este hasta que se hayan procesado todos los demás 
bloques de cliente. Por tanto, el bloque de cliente al que 
se haya hecho referencia más recientemente será el últi¬ 
mo bloque al que se vuelva a referenciar, y el bloque de 
cliente al que se haya hecho referencia menos reciente¬ 
mente será el bloque al que se vuelva a hacer referen¬ 
cia a continuación. Este conjunto de suposiciones es el 
reverso exacto del que forma la base de la estrategia 
LRU. En realidad, la estrategia óptima para la sustitu¬ 
ción de bloques es la estrategia más recientemente 


for each tupia p de prestatario do 
for each tupia c de cliente do 

if p[nombre-cliente] = c[nombre-cliente] 

then begin 

sea x una tupia definida de la manera siguiente: 
x[nombre-cliente] := p[nombre-cliente] 
x[número-préstamo] := p[número-préstamo] 
x[calle-cliente] := c[calle-cliente] 
x[ciudad-cliente] := c[ciudad-cllente] 

incluir la tupia x como parte del resultado de prestatario XI cliente 

end 


end 

end 

FIGURA 11.5. Procedimiento para calcular la reunión. 
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utilizada (Most Recently Used, MRU). Si hay que eli¬ 
minar de la memoria intermedia un bloque de cliente, 
la estrategia MRU escoge el bloque utilizado más recien¬ 
temente. 

Para que la estrategia MRU funcione correctamen¬ 
te en el ejemplo propuesto, el sistema debe clavar el blo¬ 
que de cliente que se esté procesando. Después de que 
se haya procesado la última tupia de cliente el bloque 
se desclava y se transforma en el bloque utilizado más 
recientemente. 

Además de utilizar la información que pueda tener 
el sistema respecto de la solicitud que se esté proce¬ 
sando, el gestor de la memoria intermedia puede utili¬ 
zar información estadística concerniente a la probabili¬ 
dad de que una solicitud haga referencia a una relación 
concreta. Por ejemplo, el diccionario de datos (como se 
verá en detalle en el Apartado 11.8) que guarda el esque¬ 
ma lógico de las relaciones y su información del alma¬ 
cenamiento físico es una de las partes de la base de datos 
a la que se tiene acceso con mayor frecuencia. Por tan¬ 
to, el gestor de la memoria intermedia debe intentar no 
eliminar de la memoria principal los bloques del dic¬ 
cionario de datos a menos que se vea obligado a hacer¬ 
lo por otros factores. En el Capítulo 12 se discuten los 
índices de los archivos. Dado que puede que se tenga 
acceso más frecuentemente al índice de un archivo que 
al propio archivo, el gestor de la memoria intermedia 
no deberá, en general, eliminar los bloques del índice 
de la memoria principal si se dispone de alternativas. 

La estrategia ideal para la sustitución de bloques 
necesita información sobre las operaciones de la bases 
de datos (las que se estén realizando y las que se reali¬ 
zarán en el futuro). No se conoce ninguna estrategia ais¬ 
lada que responda bien a todas las situaciones posibles. 
En realidad, un número sorprendentemente grande de 


bases de datos utilizan LRU a pesar de los defectos de 
esa estrategia. Los ejercicios exploran estrategias alter¬ 
nativas. 

La estrategia utilizada por el gestor de la memoria 
intermedia para la sustitución de los bloques se ve influi¬ 
da por factores distintos del momento en que se volve¬ 
rá a hacer referencia al bloque. Si el sistema está pro¬ 
cesando de manera concurrente las solicitudes de varios 
usuarios, puede que el subsistema para el control de la 
concurrencia (Capítulo 16) tenga que posponer ciertas 
solicitudes para asegurar la conservación de la consis¬ 
tencia de la base de datos. Si se proporciona al gestor de 
la memoria intermedia información del subsistema 
de control de la concurrencia que indique las solicitudes 
que se posponen, puede utilizar esta información para 
modificar su estrategia de sustitución de los bloques. 
De manera específica, los bloques que necesiten las soli¬ 
citudes activas (no pospuestas) pueden retenerse en la 
memoria intermedia a expensas de los bloques que nece¬ 
siten las solicitudes pospuestas. 

El subsistema para la recuperación de caídas (Capí¬ 
tulo 17) impone restricciones estrictas a la sustitución 
de los bloques. Si se ha modificado un bloque, no se 
permite al gestor de la memoria intermedia volver a 
copiar la versión nueva del bloque de la memoria inter¬ 
media al disco, dado que eso destruiría la versión ante¬ 
rior. Por el contrario, el gestor de bloques debe solici¬ 
tar permiso del subsistema para la recuperación de 
averías antes de escribir los bloques. Puede que el sub¬ 
sistema para la recuperación de averías exija que se fuer¬ 
ce la salida de otros bloques antes de conceder autori¬ 
zación al gestor de la memoria intermedia para escribir 
el bloque solicitado. En el Capítulo 17 se define con pre¬ 
cisión la interacción entre el gestor de la memoria inter¬ 
media y el subsistema para la recuperación de averías. 


11.6. ORGANIZACIÓN DE LOS ARCHIVOS 


Los archivos se organizan lógicamente como secuen¬ 
cias de registros. Estos registros se corresponden con 
los bloques del disco. Los archivos se proporcionan 
como un instrumento fundamental de los sistemas ope¬ 
rativos, por lo que se supondrá la existencia de un sis¬ 
tema de archivos subyacente. Hay que tomar en con¬ 
sideración diversas maneras de representar los modelos 
lógicos de datos en términos de archivos. 

Aunque los bloques son de un tamaño fijo determi¬ 
nado por las propiedades físicas del disco y por el sis¬ 
tema operativo, los tamaños de los registros varían. En 
las bases de datos relaciónales las tupias de las dife¬ 
rentes relaciones suelen ser de tamaños distintos. 

Un enfoque de la correspondencia entre la base de datos 
y los archivos es utilizar varios y guardar los registros de 
cada una de las diferentes longitudes fijas existentes en 
cada uno de esos archivos. Los archivos con registros 


de longitud fija son más sencillos de implementar que los 
archivos con registros de longitud variable. Muchas de 
las técnicas utilizadas para los primeros pueden aplicar¬ 
se al caso de longitud variable. Por tanto, se comienza 
considerando un archivo con registros de longitud fija. 

11.6.1. Registros de longitud fija 

A manera de ejemplo, considérese un archivo con regis¬ 
tros de cuentas de la base de datos bancaria. Cada regis¬ 
tro de este archivo se define de la manera siguiente: 

type depósito = record 

número-cuenta: char(10); 
nombre-sucursal: char (22); 
saldo: real; 

end 
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FIGURA 11.6. Archivo que contiene los registros de cuenta. 
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FIGURA 11.8. El archivo de la Figura 11.6 con el registro 2 
borrado y el último registro desplazado. 


Si se supone que cada carácter ocupa un byte y que 
un valor de tipo real ocupa ocho bytes, el registro de 
cuenta tiene cuarenta bytes de longitud. Un enfoque 
sencillo es utilizar los primeros cuarenta bytes para el 
primer registro, los cuarenta bytes siguientes para el se¬ 
gundo registro, etcétera (Figura 11.6). Sin embargo, hay 
dos problemas con este enfoque sencillo: 

1. Resulta difícil borrar un registro de esta estructu¬ 
ra. Se debe rellenar el espacio ocupado por el regis¬ 
tro que hay que borrar con algún otro registro del 
archivo o tener algún medio de marcar los regis¬ 
tros borrados para que puedan pasarse por alto. 

2. A menos que el tamaño de los bloques sea un múl¬ 
tiplo de cuarenta (lo que resulta improbable) algu¬ 
nos de los registros se saltarán los límites de los 
bloques. Es decir, parte del registro se guardará 
en un bloque y parte en otro. Harán falta, por tan¬ 
to, dos accesos a bloques para leer o escribir ese 
tipo de registros. 

Cuando se borra un registro se puede desplazar el regis¬ 
tro situado a continuación al espacio ocupado anterior¬ 
mente por el registro borrado y hacer lo mismo con los 
demás registros hasta que todos los registros situados a 
continuación del borrado se hayan desplazado hacia delan¬ 
te (Figura 11.7). Un enfoque de este tipo necesita des¬ 
plazar gran número de registros. Resultaría más sencillo 
desplazar simplemente el último registro del archivo al 
espacio ocupado por el registro borrado (Figura 11.8). 

No resulta deseable desplazar los registros para ocu¬ 
par el espacio liberado por los registros borrados, dado 
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que se necesitan accesos adicionales a los bloques. Dado 
que las inserciones tienden a ser más frecuentes que los 
borrados, sí resulta aceptable dejar libre el espacio ocu¬ 
pado por los registros borrados y esperar a una inser¬ 
ción posterior antes de volver a utilizar ese espacio. No 
basta con una simple marca en el registro borrado, dado 
que resulta difícil el espacio disponible mientras se rea¬ 
liza una inserción. Por tanto, hay que introducir una 
estructura adicional. 

Al comienzo del archivo se asigna cierto número de 
bytes como cabecera del archivo. Fa cabecera con¬ 
tendrá gran variedad de información sobre el archivo. 
Por ahora, todo lo que hace falta guardar ahí es la di¬ 
rección del primer registro cuyo contenido se haya bo¬ 
rrado. Se utiliza este primer registro para guardar la 
dirección del segundo registro disponible, y así sucesi¬ 
vamente. De manera intuitiva se pueden considerar estas 
direcciones guardadas como punteros, dado que indi¬ 
can la posición de un registro. Fos registros borrados, 
por tanto, forman una lista enlazada a la que se suele 
denominar lista libre. En la Figura 11.9 se muestra el 
archivo de la Figura 11.6 después de haberse borrado 
los registros 1,4 y 6. 

Al insertar un registro nuevo se utiliza el registro 
indicado por la cabecera. Se cambia el puntero de la 
cabecera para que apunte al siguiente registro disponi¬ 
ble. Si no hay espacio disponible, se añade el nuevo re¬ 
gistro al final del archivo. 

Fa inserción y el borrado de archivos con registros de 
longitud fija son sencillas de implementar, dado que el 
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FIGURA 11.7. El archivo de la Figura 11.6 con el registro 2 FIGURA 11.9. El archivo de la Figura 11.6 después del 
borrado y todos los registros desplazados. borrado de los registros 1, 4 y 6. 
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espacio que deja libre el registro borrado es exactamen¬ 
te el mismo que se necesita para insertar otro registro. Si 
se permiten en un archivo registros de longitud variable 
esta coincidencia no se mantiene. Puede que el registro 
insertado no quepa en el espacio liberado por el regis¬ 
tro borrado o puede que sólo llene parte del mismo. 

11.6.2. Registros de longitud variable 

Los registros de longitud variable surgen de varias mane¬ 
ras en los sistemas de bases de datos: 

• Almacenamiento de varios tipos de registros en un 
mismo archivo 

• Tipos de registro que permiten longitudes varia¬ 
bles para uno o varios de los campos 

• Tipos de registro que permiten campos repetidos 

Existen diferentes técnicas para implementar los 
registros de longitud variable. Con fines ilustrativos se 
utilizará un ejemplo para mostrar las diversas técnicas 
de implementación. Se tomará en consideración una 
representación diferente de la información de cuenta 
guardada en el archivo de la Figura 11.6, en la que se 
utiliza un registro de longitud variable para el nombre 
de cada sucursal y para toda la información de las cuen¬ 
tas de cada sucursal. El formato del registro es 

type lista-cuentas = record 

nombre-sucursal : char (22); 
información-cuenta : array [1 .. oo] of record; 

número-cuenta : char(10); 
saldo : real; 


Se define información-cuenta como un array con un 
número arbitrario de elementos, por lo que no hay nin¬ 
gún límite para el tamaño que pueden tener los regis¬ 
tros (hasta el tamaño del disco, ¡por supuesto!). 

11.6.2.1. Representación en cadenas de bytes 

Un método sencillo de implementar los registros de lon¬ 
gitud variable es adjuntar un símbolo especial de fin- 
de-registro (_L) al final de cada registro. Así se puede 
guardar cada registro como una cadena de bytes conse¬ 
cutivos. En la Figura 11.10 se muestra una organización 


de este tipo que representa el archivo con registros 
de longitud fija de la Figura 11.6 utilizando registros de 
longitud variable. Una versión alternativa de la repre¬ 
sentación en cadenas de bytes guarda la longitud del 
registro al comienzo de cada registro en lugar de utili¬ 
zar símbolos de final de registro. 

La representación en cadenas de bytes tal y como se 
ha discutido presenta varios inconvenientes: 

• No resulta sencillo volver a utilizar el espacio ocu¬ 
pado anteriormente por un registro borrado. Aun¬ 
que existen técnicas para gestionar la inserción y 
el borrado de registros, generan gran número de 
fragmentos pequeños de almacenamiento de dis¬ 
co desaprovechados. 

• Por lo general no queda espacio para el aumento 
del tamaño de los registros. Si un registro de lon¬ 
gitud variable aumenta de tamaño hay que despla¬ 
zarlo (el movimiento resulta costoso si el registro 
está almacenado en otro lugar de la base de datos; 
por ejemplo, en los índices o en otros registros), ya 
que los punteros se deben localizar y actualizar. 

Por tanto, no se suele utilizar la representación sen¬ 
cilla en cadenas de bytes tal y como aquí se ha descri¬ 
to para implementar registros de longitud variable. Sin 
embargo, una forma modificada de la representación en 
cadenas de bytes, denominada estructura de páginas con 
ranuras, se utiliza normalmente para organizar los regis¬ 
tros dentro de cada bloque. 

La estructura de páginas con ranuras se muestra 
en la Figura 11.11. Hay una cabecera al principio de 
cada bloque que contiene la información siguiente: 

1. El número de elementos del registro de la cabe¬ 
cera 

2. El final del espacio vacío del bloque 

3. Un array cuyas entradas contienen la ubicación 
y el tamaño de cada registro 

Los registros reales se ubican de manera contigua 
en el bloque, empezando desde el final del mismo. El 
espacio libre dentro del bloque es contiguo, entre la últi¬ 
ma entrada del array de la cabecera y el primer regis¬ 
tro. Si se inserta un registro se le asigna espacio al final 
del espacio libre y se añade a la cabecera una entrada 
que contiene su tamaño y su ubicación. 
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FIGURA 11.10. Representación en cadenas de bytes de los registros de longitud variable. 
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Cabecera de bloque Registros 
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Fin del espacio libre 
FIGURA 11.11. Estructura de páginas con ranuras. 
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Espacio libre 


Si se borra un registro se libera el espacio que ocupa 
y se da el valor de «borrada» a su entrada (por ejemplo, 
se le da a su tamaño el valor de -1). Además, se despla¬ 
zan los registros de bloque situados antes del registro 
borrado, de modo que se ocupe el espacio libre creado 
por el borrado y todo el espacio libre vuelve a hallarse 
entre la última entrada del array de la cabecera y el pri¬ 
mer registro. También se actualiza de manera adecuada 
el puntero de final del espacio libre de la cabecera. Se 
puede aumentar o disminuir el tamaño de los registros 
utilizando técnicas parecidas, siempre y cuando quede 
espacio en el bloque. El coste de trasladar los registros 
no es demasiado elevado, dado que el tamaño del blo¬ 
que es limitado: un valor típico es cuatro kilobytes. 

La estructura de páginas con ranuras necesita que no 
haya punteros que apunten directamente a los registros. 
Por el contrario, los punteros deben apuntar a la entra¬ 
da de la cabecera que contiene la ubicación verdadera 
del registro. Este nivel de indirección permite a los regis¬ 
tros desplazarse para evitar la fragmentación del espa¬ 
cio dentro del bloque al tiempo que permite los punte¬ 
ros indirectos a los registros. 

11.6.2.2. Representación de longitud tija 

Otra manera de implementar eficientemente los regis¬ 
tros de longitud variable en un sistema de archivos es 
utilizar uno o varios registros de longitud fija para repre¬ 
sentar cada registro de longitud variable. 

Hay dos técnicas para hacer esto: 

1. Espacio reservado. Si hay una longitud de regis¬ 
tro máxima que no se supera nunca, se pueden 
utilizar registros de longitud fija de esa longitud. 
El espacio no utilizado (por los registros más cor¬ 
tos que el espacio máximo) se rellena con un sím¬ 
bolo especial de valor nulo o de final de registro. 


2. Representación con listas. El registro de longi¬ 
tud variable se representa mediante una lista de 
registros de longitud fija, enlazada mediante pun¬ 
teros. 

Si se escoge aplicar el método del espacio reserva¬ 
do al ejemplo de las cuentas bancarias hay que selec¬ 
cionar una longitud de registro máxima. En la Figura 
11.12 se muestra el modo en que se representaría el 
archivo si se permitiera un máximo de tres cuentas por 
sucursal. Los registros de este archivo son del tipo lis¬ 
ta-cuentas, pero el array contiene exactamente tres 
elementos. Las sucursales con menos de tres cuentas 
(por ejemplo, Collado Mediano) tienen registros con 
campos con valores nulos. En la Figura 11.12 se uti¬ 
liza el símbolo -L para representar esta situación. En 
la práctica se utiliza un valor concreto que no pueda 
representar nunca un dato real (por ejemplo, un «núme¬ 
ro de cuenta» negativo o un nombre que comience por 
un «*»). 

El método del espacio reservado resulta útil cuando 
la mayor parte de los registros son de una longitud cer¬ 
cana a la máxima. En caso contrario se puede desper¬ 
diciar una cantidad de espacio significativa. En el ejem¬ 
plo bancario puede que algunas sucursales tengan 
muchas más cuentas que otras. Esta situación lleva a 
considerar el uso del método de las listas enlazadas. Para 
representar el archivo utilizando el método de los pun¬ 
teros se añade un campo puntero igual que se hizo en 
la Figura 11.9. La estructura resultante se muestra en la 
Figura 11.13. 

Las estructuras de archivo de las Figuras 11.9 y 11.13 
son idénticas, salvo que en la Figura 11.9 sólo se utili¬ 
zaron los punteros para enlazar los registros borrados, 
mientras que en la Figura 11.13 se enlazan todos los 
registros pertenecientes a la misma sucursal. 
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FIGURA 11.12. El archivo de la Figura 11.10 utilizando el método del espacio reservado. 
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3 
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6 

7 
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Navacerrada 

C-102 

80.000 ■ 

Collado Mediano 

C-305 

70.000 

Becerril 

C-215 

140.000 

Centro 

C-101 

100.000 

Moralzarzal 

C-222 

140.000 
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180.000 

Galapagar 

C-217 

150.000 


C-110 

120.000 


C-218 

140.000 


1. Bloque ancla, que contiene el primer registro de 
cada cadena. 

2. Bloque de desbordamiento, que contiene los 
registros que no son los primeros de sus cadenas. 

Por tanto, todos los registros del interior de cada blo¬ 
que tienen la misma longitud, aunque no todos los regis¬ 
tros del archivo tengan la misma longitud. En la Figu¬ 
ra 11.14 se muestra esta estructura de archivos. 


FIGURA 11.13. El archivo de la Figura 11.10 utilizando el 
método de las listas enlazadas. 

Un inconveniente de la estructura de la Figura 11.13 
es que se desperdicia espacio en todos los registros 
excepto en el primero de la serie. El primer registro debe 
tener el valor nombre-sucursal, pero los registros 
siguientes no necesitan tenerlo. No obstante, hay que 
incluir en todos los registros un campo para nombre- 
sucursal, o los registros no serán de longitud constan¬ 
te. El espacio desperdiciado es significativo, dado que 
se espera en la práctica que cada sucursal tenga un gran 
número de cuentas. Para resolver este problema se per¬ 
miten en el archivo dos tipos de bloques: 
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FIGURA 11.14. Estructuras de bloque ancla y de bloque de 
desbordamiento. 


11.7. ORGANIZACIÓN DE LOS REGISTROS EN ARCHIVOS 


Hasta ahora se ha estudiado la manera en que se repre¬ 
sentan los registros en la estructura de los archivos. Un 
conjunto de registros constituye un ejemplo de esta rela¬ 
ción. Dado un conjunto de registros, la pregunta siguien¬ 
te es la manera de organizarlos en archivos. A conti¬ 
nuación se indican varias de las maneras de organizar 
los registros en archivos: 

• Organización de archivos en montículo. En esta 
organización se puede colocar cualquier registro en 
cualquier parte del archivo en que haya espacio sufi¬ 
ciente. No hay ninguna ordenación de los registros. 
Generalmente sólo hay un archivo por cada relación. 

• Organización de archivos secuenciales. En esta 
organización los registros se guardan en orden 
secuencial, basado en el valor de la clave de bús¬ 
queda de cada registro. La implementación de esta 
organización se describe en el Apartado 11.7.1. 

• Organización asociativa ( hash ) de archivos. En 

esta organización se calcula una función de aso¬ 
ciación (hash) de algún atributo de cada registro. 
El resultado de la función de asociación especifi¬ 
ca el bloque del archivo en que se deberá colocar 
el registro. Esta organización se describe en el 
Capítulo 12; está estrechamente relacionada con 
las estructuras para la creación de índices descri¬ 
tas en dicho capítulo. 


Generalmente se usa un archivo separado para alma¬ 
cenar los registros de cada relación. Sin embargo, en 
una organización de archivos en agrupaciones se 
pueden guardar en el mismo archivo registros de rela¬ 
ciones diferentes; además, los registros relacionados 
de las diferentes relaciones se guardan en el mismo 
bloque, por lo que cada operación de E/S afecta a regis¬ 
tros relacionados de todas esas relaciones. Por ejem¬ 
plo, los registros de las dos relaciones se pueden con¬ 
siderar relacionados si casan en una reunión de las dos 
relaciones. Esta organización se describe en el Apar¬ 
tado 11.7.2. 

11.7.1. Organización de archivos secuenciales 

Los archivos secuenciales están diseñados para el pro¬ 
cesamiento eficiente de los registros de acuerdo con un 
orden basado en una clave de búsqueda. Una clave de 
búsqueda es cualquier atributo o conjunto de atributos; 
no tiene por qué ser una clave primaria, ni siquiera una 
superclave. Para permitir la recuperación rápida de los 
registros según el orden de la clave de búsqueda, los re¬ 
gistros se vinculan mediante punteros. El puntero de 
cada registro apunta al siguiente registro según el orden 
indicado por la clave de búsqueda. Además, para mini¬ 
mizar el número de accesos a los bloques en el proce¬ 
samiento de los archivos secuenciales, los registros se 
guardan físicamente de acuerdo con el orden indicado 


268 







































CAPÍTULO 11 ALMACENAMIENTO Y ESTRUCTURA DE ARCHIVOS 


por la clave de búsqueda, o en un orden tan cercano a 
éste como sea posible. 

En la Figura 11.15 se muestra un archivo secuencial 
de registros de cuenta tomado del ejemplo bancario pro¬ 
puesto. En ese ejemplo los registros se guardan de acuer¬ 
do con el orden de la clave de búsqueda, utilizando como 
tal nombre-sucursal. 

La organización secuencial de archivos permite que 
los registros se lean de forma ordenada, lo que puede 
ser útil para la visualización, así como para ciertos algo¬ 
ritmos de procesamiento de consultas que se estudiarán 
en el Capítulo 13. 

Sin embargo, resulta difícil mantener el orden físico 
secuencial cuando se insertan y borran registros, dado 
que resulta costoso desplazar muchos registros como 
consecuencia de una sola inserción o borrado. Se pue¬ 
de gestionar el borrado utilizando cadenas de punteros, 
como ya se ha visto anteriormente. Para la inserción se 
aplican las reglas siguientes: 

1. Localizar el registro del archivo que precede al 
registro que se va a insertar en el orden de la cla¬ 
ve de búsqueda. 

2. Si existe algún registro vacío (es decir, un espa¬ 
cio que haya quedado libre después de un borra¬ 
do) dentro del mismo bloque que ese registro, el 
registro nuevo se insertará ahí. En caso contrario 
el nuevo registro se insertará en un bloque de des¬ 
bordamiento. En cualquier caso, hay que ajustar 
los punteros para vincular los registros según el 
orden de la clave de búsqueda. 

En la Figura 11.16 se muestra el archivo de la Figu¬ 
ra 11.15 después de la inserción del registro (C-888, 
Leganés, 800). La estructura de la Figura 11.16 permi¬ 
te la inserción rápida de nuevos registros, pero obliga a 
las aplicaciones de procesamiento de archivos secuen- 
ciales a procesar los registros en un orden que no coin¬ 
cide con su orden físico. 

Si hay que guardar un número relativamente peque¬ 
ño de registros en los bloques de desbordamiento, este 
enfoque funciona bien. Finalmente, sin embargo, la 
correspondencia entre el orden de la clave de búsque¬ 
da y el orden físico puede perderse totalmente, en cuyo 
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FIGURA 11.15. Archivo secuencial para los registros de 
cuenta. 
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FIGURA 11.16. El archivo secuencial después de una inser¬ 
ción. 

caso el procesamiento secuencial será significativamente 
menos eficiente. Llegados a este punto se debe reor¬ 
ganizar el archivo de modo que vuelva a estar física¬ 
mente en orden secuencial. Estas reorganizaciones resul¬ 
tan costosas y deben realizarse en momentos en los que 
la carga del sistema sea baja. La frecuencia con la que se 
necesitan las reorganizaciones depende de la frecuen¬ 
cia de inserción de registros nuevos. En el caso extre¬ 
mo en que las inserciones tengan lugar raramente, siem¬ 
pre resultará posible mantener el archivo en el orden 
físico correcto. En ese caso no es necesario el campo 
puntero mostrado en la Figura 11.15. 

11.7.2. Organización de archivos 
en agrupaciones 

Muchos sistemas de bases de datos relaciónales guardan 
cada relación en un archivo diferente de modo que pue¬ 
dan aprovechar completamente el sistema de archivos que 
forma parte del sistema operativo. Generalmente las tupias 
de cada relación pueden representarse como registros de 
longitud fija. Por tanto, las relaciones pueden hacerse 
corresponder con una estructura de archivos sencilla. Esta 
implementación sencilla de los sistemas de bases de datos 
relaciónales resulta adecuada para los sistemas de bases 
de datos diseñados para computadoras personales. En 
estos sistemas el tamaño de la base de datos es pequeño, 
por lo que se obtiene poco provecho de una estructura de 
archivos avanzada. Además, en algunas computadoras 
personales el pequeño tamaño global del código objeto 
del sistema de bases de datos resulta fundamental. Una 
estructura de archivos sencilla reduce la cantidad de códi¬ 
go necesaria para implementar el sistema. 

Este enfoque sencillo de la implementación de bases 
de datos relaciónales resulta menos satisfactorio a me¬ 
dida que aumenta el tamaño de la base de datos. Ya se 
ha visto que se pueden obtener ventajas en el rendi¬ 
miento mediante la asignación esmerada de los registros 
a los bloques y de la organización cuidadosa de los pro¬ 
pios bloques. Por tanto, resulta evidente que puede resul¬ 
tar beneficiosa una estructura de archivos más comple¬ 
ja, aunque se mantenga la estrategia de guardar cada 
relación en un archivo diferente. 
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nombre-cliente 

número-cuenta 
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FIGURA 11.17. La relación impositor. 

Sin embargo, muchos sistemas de bases de datos de 
gran tamaño no utilizan directamente el sistema opera¬ 
tivo subyacente para la gestión de archivos. Por el con¬ 
trario, se asigna al sistema de bases de datos un archi¬ 
vo de gran tamaño del sistema operativo. En este archivo 
se guardan todas las relaciones y se confía la gestión de 
este archivo al sistema de bases de datos. Para ver la 
ventaja de guardar muchas relaciones en un solo archi¬ 
vo considérese la siguiente consulta SQL de la base de 
datos bancaria: 

select número-cuenta, nombre-cliente, calle-cliente, 

ciudad-cliente 
from impositor, cliente 

where impositor.nombre-cliente = cliente.nombre- 

cliente 

Esta consulta calcula una reunión de las relaciones 
impositor y cliente. Por tanto, por cada tupia impositor 
el sistema debe encontrar las tupias cliente con el mis¬ 
mo valor de nombre-cliente. En teoría, estos registros 
se podrán encontrar con la ayuda de los índices, que se 
discutirán en el Capítulo 12. Independientemente de la 
manera en que se encuentren estos registros hay que 
transferirlos desde el disco a la memoria principal. En 
el peor de los casos cada registro se hallará en un blo¬ 
que diferente, lo que obligará a efectuar un proceso de 
lectura de bloque por cada registro necesario para la 
consulta. 

Como ejemplo concreto, considérense las relaciones 
impositor y cliente de las Figuras 11.17 y 11.18, res¬ 
pectivamente. En la Figura 11.19 se muestra una estruc¬ 
tura de archivo diseñada para la ejecución eficiente de 
las consultas que implican impositor tx cliente. Las 
tupias impositor para cada nombre-cliente se guardan 
cerca de la tupia cliente para el nombre-cliente corres¬ 
pondiente. Esta estructura mezcla las tupias de dos rela¬ 
ciones pero permite el procesamiento eficaz de la reu¬ 
nión. Cuando se lee una tupia de la relación cliente se 
copia del disco a la memoria principal todo el bloque 
que contiene esa tupia. Dado que las tupias correspon¬ 
dientes de impositor se guardan en el disco cerca de la 
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FIGURA 11.18. La relación cliente. 
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FIGURA 11.19. Estructura de archivo en agrupaciones. 

tupia cliente, el bloque que contiene la tupia cliente tam¬ 
bién contiene las tupias de la relación impositor nece¬ 
sarias para procesar la consulta. Si un cliente tiene tan¬ 
tas cuentas que los registros de impositor no caben en 
un solo bloque, los registros restantes aparecerán en blo¬ 
ques cercanos. 

Una organización de archivos en agrupaciones es 

una organización de archivos, como la mostrada en la 
Figura 11.19 que almacena registros relacionados de 
dos o más relaciones en cada bloque. Esta organización 
permite leer muchos de los registros que satisfacen la 
condición de reunión utilizando un solo proceso de lec¬ 
tura de bloques. Por tanto, se puede procesar esta con¬ 
sulta concreta de manera más eficiente. 

Este uso de la agrupación ha mejorado el procesa¬ 
miento de una reunión particular ( impositor M cliente) 
pero ha producido el retardo del procesamiento de otros 
tipos de consulta. Por ejemplo, 

select * 

from cliente 

necesita más accesos a los bloques que en el esquema 
en el que se guardaba cada relación en un archivo dife¬ 
rente. En lugar de que aparezcan varios registros de 
cliente en un mismo bloque, cada registro se halla en 
un bloque diferente. En realidad, hallar todos los regis¬ 
tros de cliente no resulta posible sin alguna estructura 
adicional. Para encontrar todas las tupias de la relación 
cliente en la estructura de la Figura 11.19 hay que vincu¬ 
lar todos los registros de esa relación utilizando punte¬ 
ros, tal y como se muestra en la Figura 11.20. 

La determinación del momento de utilizar la agru¬ 
pación depende de los tipos de consulta que el diseña¬ 
dor de la base de datos considere más frecuentes. El uso 
cuidadoso de la agrupación puede producir ganancias 
de rendimiento significativas en el procesamiento de 
consultas. 
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FIGURA 11.20. Estructura de archivo con agrupaciones 
con cadenas de punteros. 
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11.8. ALMACENAMIENTO CON DICCIONARIOS DE DATOS 


Hasta ahora sólo se ha considerado la representación de 
las propias relaciones. Un sistema de bases de datos rela¬ 
ciónales necesita tener datos sobre las relaciones, como 
el esquema de las mismas. Esta información se deno¬ 
mina diccionario de datos o catálogo del sistema. 
Entre los tipos de información que debe guardar el sis¬ 
tema figuran los siguientes: 

• Los nombres de las relaciones 

• Los nombres de los atributos de cada relación 

• Los dominios y las longitudes de los atributos 

• Los nombres de las vistas definidas en la base de 
datos y las definiciones de esas vistas 

• Las restricciones de integridad (por ejemplo, las 
restricciones de las claves) 

Además, muchos sistemas guardan los datos siguien¬ 
tes de los usuarios del sistema: 

• Los nombres de los usuarios autorizados 

• La información de las cuentas de usuarios 

• Contraseñas u otra información usada para auten¬ 
ticar a los usuarios 

Además, se puede guardar información estadística y 
descriptiva sobre estos asuntos: 

• Número de tupias de cada relación 

• Método de almacenamiento utilizado para cada 
relación (por ejemplo, con agrupaciones o sin agru¬ 
paciones) 

El diccionario de datos puede también anotar la orga¬ 
nización del almacenamiento (secuencial, asociativa o 
con montículos) de las relaciones y la ubicación donde 
se almacena cada relación: 

• Si las relaciones se almacenan en archivos del sis¬ 
tema operativo, el diccionario no podría anotar 


los nombres de los archivos que almacenan cada 
relación. 

• Si la base de datos almacena todas las relaciones 
en un único archivo, el diccionario puede anotar 
los bloques que almacenan los registros de cada 
relación en una estructura de datos como una lis¬ 
ta enlazada. 

En el Capítulo 12, en el que se estudian los índices, 
se verá que hace falta guardar información sobre cada 
índice de cada una de las relaciones: 

• El nombre del índice 

• El nombre de la relación para la que se crea el índi¬ 
ce 

• Los atributos sobre los que se define el índice 

• El tipo de índice formado 

Toda esta información constituye, en efecto, una base 
de datos en miniatura. Algunos sistemas de bases de datos 
guardan esta información utilizando estructuras de datos 
y código especiales. Suele resultar preferible guardar los 
datos sobre la base de datos en la misma base de datos. 
Al utilizar la base de datos para guardar los datos del sis¬ 
tema se simplifica la estructura global del sistema y se 
permite que se utilice toda la potencia de la base de datos 
en obtener un acceso rápido a los datos del sistema. 

La elección exacta de la manera de representar los 
datos del sistema utilizando relaciones debe tomarla el 
diseñador del sistema. A continuación se ofrece una 
representación posible con las claves primarias subra¬ 
yadas: 

Metadatos-catálogo-sistema = ( nombre-relación , 
número-atributos) 

Metadatos-atributos = ( nombre-atributo , nombre- 
relación . tipo-dominio, posición, longitud) 
Metaclatos-usuarios = ( nombre-usuario . contraseña- 
cifrada, grupo) 

Metadatos-índices = ( nombre-índice , nombre-relación . 

tipo-índice, atributos-índice) 

Metadatos-vistas = ( nombre-vista , definición) 


11.9. ALMACENAMIENTO PARA LAS BASES DE DATOS ORIENTADAS 
A OBJETOS** 


Las técnicas de organización de los archivos descritas en 
el Apartado 11.7 (como las organizaciones en montícu¬ 
lo, secuencial, asociativa y de agrupaciones) también pue¬ 
den utilizarse para guardar los objetos de las bases de 


datos orientadas a objetos. Sin embargo, se necesitan 
características adicionales para poder trabajar con las pro¬ 
piedades de las bases de datos orientadas a objetos, como 
los campos de conjuntos y los punteros persistentes. 
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11.9.1. Correspondencia de los objetos 
con los archivos 

La correspondencia de los objetos con los archivos 
tiene gran parecido con la correspondencia de las tupias 
con los archivos de los sistemas relaciónales. En el nivel 
inferior de la representación de los datos, tanto las par¬ 
tes de tupias de los objetos como las de datos, son sen¬ 
cillamente secuencias de bytes. Por tanto, se pueden 
guardar los datos de los objetos utilizando las estruc¬ 
turas de archivos descritas en los apartados anteriores 
con algunas modificaciones que se indican a continua¬ 
ción. 

Los objetos de las bases de datos orientadas a obje¬ 
tos pueden carecer de la uniformidad de las tupias de 
las bases de datos relaciónales. Por ejemplo, los cam¬ 
pos de los registros pueden ser conjuntos, a diferen¬ 
cia de las bases de datos relaciónales, en los que se 
suele exigir que los datos se encuentren (por lo menos) 
en la primera forma normal. Además, los objetos pue¬ 
den ser muy grandes. Hay que tratar estos objetos de 
manera diferente de los registros de los sistemas rela¬ 
ciónales. 

Se pueden implementar campos de conjuntos que 
tengan un número pequeño de elementos que utilicen 
estructuras de datos como las listas enlazadas. Los cam¬ 
pos de conjuntos que tienen un número de elementos 
mayor pueden implementarse como relaciones en la 
base de datos. Los campos de conjuntos también pue¬ 
den borrarse en el nivel de almacenamiento mediante 
la normalización: se crea una relación que contenga una 
tupia para cada valor del campo de conjunto de un obje¬ 
to. Cada tupia también contiene el identificador del ob¬ 
jeto. El sistema de almacenamiento da a los niveles 
superiores del sistema de bases de datos el aspecto de 
un campo de conjuntos, aunque en realidad el campo 
de conjuntos se haya normalizado para crear una rela¬ 
ción nueva. 

Algunas aplicaciones incluyen objetos muy grandes 
que no se descomponen fácilmente en componentes 
menores. Cada uno de estos objetos de gran tamaño pue¬ 
de guardarse en un archivo diferente. Esta idea se dis¬ 
cute en el Apartado 11.9.6. 


11.9.2. Imple mentación de los identificadores 
de los objetos 

Dado que los objetos se identifican mediante los iden¬ 
tificadores de los objetos (IDO), los sistemas de alma¬ 
cenamiento de objetos necesitan un mecanismo para 
encontrar un objeto dado su IDO. Si los IDOs son lógi¬ 
cos (es decir, no especifican la ubicación del objeto) 
el sistema de almacenamiento debe tener un índice 
que asocie los IDOs con la ubicación real del objeto. 
Si los IDOs son físicos (es decir, codifican la ubica¬ 
ción del objeto) se puede encontrar el objeto directa¬ 
mente. Los IDOs físicos suelen tener las tres partes 
siguientes: 

1. Un identificador de volumen o de archivo 

2. Un identificador de las páginas dentro del volu¬ 
men o archivo 

3. Un desplazamiento dentro de la página 

Además, los IDOs físicos pueden contener un iden¬ 
tificador único, que es un entero que distingue el IDO 
de los identificadores de los demás objetos que se hayan 
guardado anteriormente en la misma ubicación y se 
borraron o se trasladaron a otra parte. El identificador 
único también se guarda con el objeto y deben coinci¬ 
dir los identificadores del IDO y los del objeto corres¬ 
pondiente. Si el identificador único de un IDO físico no 
coincide con el identificador único del objeto al que 
apunta el IDO, el sistema detecta que el puntero es un 
puntero colgante e indica un error (un puntero colgante 
es un puntero que no apunta a un objeto válido). En la 
Figura 11.21 se ilustra este esquema. 

Estos errores de puntero tienen lugar cuando se uti¬ 
lizan de manera accidental IDOs físicos correspon¬ 
dientes a objetos antiguos que han sido borrados. Si el 
espacio ocupado por el objeto se ha vuelto a asignar, 
puede que haya un objeto nuevo en esa ubicación, y se 
puede dirigir a él de manera incorrecta el identificador 
del objeto antiguo. Si no se detecta el uso de los punte¬ 
ros colgantes se puede dar lugar al deterioro del objeto 
nuevo guardado en la misma ubicación. El identifica¬ 
dor único ayuda a detectar estos errores, dado que los 


Identificador 


dentificador del objeto físico 


Ubicación 

único 

Datos 

Volumen. Bloque. Desplazamiento 

Identificador único 

519.56850.1200 

51 



Objeto 


Identificador único 


Datos 


IDO adecuado 


IDO inadecuado 


519.56850.1200 

51 


519.56850.1200 

50 


(a) Estructura general (b) Ejemplo de utilización 

FIGURA 11.21. Identificadores únicos de un IDO. 
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identificadores únicos del IDO físico antiguo y el del 
nuevo objeto no coinciden. 

Supóngase que hay que desplazar un objeto a una 
página nueva, quizás debido a que ha aumentado el 
tamaño del mismo y la página antigua no dispone de 
espacio adicional. En ese caso, el IDO físico apuntará 
a la página antigua, que ya no contiene el objeto. En vez 
de cambiar el IDO del objeto (lo que implica cambiar 
todos los objetos que apunten hacia él) se deja una direc¬ 
ción de entrega en la ubicación antigua. Cuando la base 
de datos intente encontrar el objeto encontrará la direc¬ 
ción de entrega en su lugar; entonces, utilizará la di¬ 
rección de entrega para encontrar el objeto. 

11.9.3. Gestión de los punteros persistentes 

Los punteros persistentes se implementan en un lenguaje 
de programación persistente utilizando los IDOs. En 
algunas implementaciones los punteros persistentes son 
IDOs físicos; en otras, son IDOs lógicos. Una diferen¬ 
cia importante entre los punteros persistentes y los pun¬ 
teros internos de memoria es el tamaño de los mismos. 
Los punteros intemos de memoria sólo necesitan tener 
el tamaño suficiente para apuntar a toda la memoria vir¬ 
tual. En las computadoras actuales los punteros internos 
de memoria tienen una longitud de cuatro bytes, que es 
suficiente para apuntar a cuatro gigabytes de memoria. 
Las nuevas arquitecturas tienen punteros de ocho bytes. 

Los punteros persistentes tienen que apuntar a todos 
los datos de la base de datos. Dado que los sistemas de 
bases de datos suelen ser mayores que cuatro gigaby¬ 
tes, los punteros persistentes suelen tener una longitud 
de al menos ocho bytes. Muchas bases de datos orien¬ 
tadas a objetos proporcionan también identificadores 
únicos en los punteros persistentes para detectar las refe¬ 
rencias colgantes. Esta característica aumenta aún más 
el tamaño de los punteros persistentes. Por tanto, los 
punteros persistentes son de una longitud considera¬ 
blemente mayor que los punteros intemos de memoria. 

La acción de buscar un objeto dado su identificador 
se denomina desreferenciar. Dado un puntero interno 
de memoria (como en C++) buscar el objeto es simple¬ 
mente una referencia a la memoria. Dado un puntero 
persistente, desreferenciar un objeto tiene una etapa adi¬ 
cional: hay que encontrar la ubicación real del objeto 
en la memoria buscando el puntero persistente en una 
tabla. Si el objeto no se halla todavía en la memoria hay 
que cargarlo desde el disco. Se puede implementar la 
búsqueda en la tabla de manera bastante eficiente utili¬ 
zando funciones de asociación, pero la búsqueda sigue 
siendo lenta comparada con la desreferencia de los pun¬ 
teros, aunque el objeto ya se encuentre en memoria. 

El rescate de punteros es una manera de reducir el 
coste de encontrar los objetos persistentes que ya se 
hallen en la memoria. La idea es que, cuando se desre¬ 
ferencia por primera vez un puntero persistente, se 
encuentra el objeto y se lleva a la memoria si es que no 
está ya allí. Ahora se da un paso adicional (se guarda un 


puntero intemo de memoria para el objeto en lugar del 
puntero persistente). La siguiente ocasión en que se des- 
referencie el mismo puntero persistente la ubicación 
interna en la memoria puede leerse directamente, por lo 
que se evita el coste de encontrar el objeto. (En caso de 
que se puedan volver a desplazar los objetos persisten¬ 
tes de la memoria al disco para hacer sitio para otros 
objetos persistentes hay que dar otro paso más para ase¬ 
gurarse de que el objeto siga estando en la memoria). 
De manera análoga, cuando se copia al disco un objeto, 
hay que devolver todos los punteros persistentes que 
contenga y que se hubieran rescatado y hay que volver 
a convertirlos en su representación persistente. El res¬ 
cate de los punteros al efectuar su desreferencia, tal y 
como se ha descrito aquí, se denomina rescate software. 

La gestión de la memoria intermedia es más com¬ 
pleja si se utiliza el rescate de punteros, dado que la ubi¬ 
cación física de un objeto no debe cambiar una vez que 
se lleva ese objeto a la memoria intermedia. Una mane¬ 
ra de asegurarse de que no cambiará es clavar las pági¬ 
nas que contengan objetos rescatados en la memoria 
intermedia, de manera que no sean sustituidas hasta que 
el programa que realizó el rescate haya concluido. Véan¬ 
se las notas bibliográficas para tener información sobre 
esquemas de gestión de la memoria intermedia más com¬ 
plejos, que incluyen técnicas de correspondencia de la 
memoria virtual, que eliminan la necesidad de clavar 
las páginas de la memoria intermedia. 

11.9.4. Rescate hardware 

La existencia de dos tipos de punteros, persistentes y 
transitorios (internos de la memoria), resulta poco con¬ 
veniente. Los programadores tienen que recordar el tipo 
de puntero y puede que tengan que escribir el código 
dos veces (una para los punteros persistentes y otra para 
los punteros internos de la memoria). Resultaría más 
conveniente que tanto los punteros persistentes como 
los internos de la memoria fueran del mismo tipo. 

Una manera sencilla de combinar los tipos de pun¬ 
tero persistente e intemo de la memoria es extender sim¬ 
plemente la longitud de los punteros internos de la 
memoria hasta el mismo tamaño que tienen los punte¬ 
ros persistentes y utilizar un bit del identificador para 
distinguir entre punteros persistentes e internos de la 
memoria. Sin embargo, el coste de almacenamiento de 
los punteros persistentes de mayor longitud tienen que 
soportarlo también los punteros internos de la memo¬ 
ria; por tanto, este esquema no se utiliza mucho. 

Se describirá una técnica denominada rescate hard¬ 
ware que utiliza el hardware para la gestión de la memo¬ 
ria presente en la mayor parte de los sistemas informá¬ 
ticos actuales para abordar este problema. Cuando se 
accede a los datos de una página en memoria virtual y 
el sistema operativo detecta que la página no tiene alma¬ 
cenamiento real asignado, o que ha sido protegida con¬ 
tra accesos, entonces ocurre una violación de la seg¬ 
mentación 3 . Muchos sistemas operativos proporcionan 
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un mecanismo para especificar una función a la que se 
llama cuando sucede una violación de segmentación, y 
también un mecanismo para asignar almacenamiento 
para una página en el espacio virtual de direcciones y 
para establecer los permisos de acceso a la página. En 
la mayoría de sistemas Unix, la llamada al sistema mmap 
proporciona esta última característica. El rescate hard¬ 
ware hace un uso inteligente de los mecanismos ante¬ 
riores. 

El rescate hardware presenta dos ventajas funda¬ 
mentales respecto al rescate software. 

1. Puede guardar los punteros persistentes en los 
objetos en el mismo espacio que necesitan los 
punteros internos de la memoria (junto con el 
almacenamiento adicional externo al objeto). 

2. Transforma de manera transparente los punteros 
persistentes en internos de la memoria, y vice¬ 
versa, de forma inteligente y eficiente. El soft¬ 
ware escrito para trabajar con los punteros inter¬ 
nos de la memoria puede, por tanto, trabajar 
también con los punteros persistentes sin que haya 
necesidad de efectuar ningún cambio. 

11.9.4.1. Representación de punteros 

El rescate hardware utiliza la siguiente representación 
de los punteros persistentes contenidos en los objetos 
que se hallan en el disco. Un puntero persistente se divi¬ 
de conceptualmente en dos partes: un identificador de 
página en la base de datos y un desplazamiento en la 
misma página 4. El identificador de la página es en rea¬ 
lidad un puntero indirecto de pequeño tamaño: cada 
página (u otra unidad de almacenamiento) tiene una 
tabla de traducción que proporciona una asociación entre 
los identificadores de página cortos y los identificado- 
res de página completos de la base de datos. El sistema 
tiene que buscar el identificador de página corto en los 
punteros persistentes de la tabla de traducción para 
encontrar el identificador de página completo. 

La tabla de traducción, en el peor de los casos, sólo 
tendrá un tamaño igual que el número máximo de pun¬ 
teros que puedan contener los objetos de una página; 
con un tamaño de página de 4.096 y un tamaño de pun¬ 
tero de cuatro bytes el número máximo de punteros es 
1.024. En la práctica, la tabla de traducción probable¬ 
mente contenga muchos menos elementos que el núme¬ 
ro máximo (1.024 en este ejemplo) y no ocupe dema¬ 
siado espacio. El identificador de página corto sólo tiene 
que tener los bytes necesarios para identificar una fila 
de la tabla; con un tamaño de tabla máximo de 1.024 
sólo hacen falta diez bytes. Por tanto, basta con un núme¬ 


3 A veces se usa el término fallo de página en lugar de violación de 
la segmentación, aunque las violaciones de protección de acceso no 
se consideran como fallos de página. 


ro pequeño de bits para guardar el identificador de pági¬ 
na corto. Por tanto, la tabla de traducción permite que 
los punteros persistentes que no sean cortos quepan en 
el mismo espacio que los punteros intemos de la memo¬ 
ria. Aunque sólo hacen falta unos pocos bits para los 
identificadores de página cortos, se utilizan como tales 
todos los bits de los punteros internos de la memoria 
distintos de los de desplazamiento de página. Esta arqui¬ 
tectura, como se verá, facilita el rescate. 

La representación del esquema de punteros persis¬ 
tentes se muestra en la Figura 11.22, en la que hay tres 
objetos en la página, cada uno de los cuales contiene un 
puntero persistente. La tabla de traducción muestra la 
asociación entre los identificadores de página cortos y 
los identificadores de página sin abreviar de la base de 
datos para cada uno de los identificadores de página cor¬ 
tos de estos punteros persistentes. Los identificadores 
de página de la base de datos se muestran en el forma¬ 
to volumen.página.desplazamiento. 

Se guarda información adicional con cada página para 
que se puedan encontrar todos los punteros persistentes 
de la página. El sistema actualiza la información cuan¬ 
do se crea o borra algún objeto de la página. La necesi¬ 
dad de encontrar todos los punteros persistentes de cada 
página se pondrá de manifiesto más adelante. 

11.9.4.2. Rescate de punteros en una página 

Inicialmente no se ha iniciado ninguna página en 
memoria virtual. Las páginas de la memoria virtual se 
pueden asignar a las páginas de la base de datos antes 
de que realmente se carguen, como se verá enseguida. 
Las páginas de la base de datos se cargan en memoria 
virtual cuando el sistema de bases de datos necesite 
acceder a los datos de la página. Antes de que se car¬ 
gue una página de la base de datos, el sistema asigna 
una página de memoria virtual para ella si no se hubie¬ 
se asignado ya una. El sistema carga la página de la 
base de datos en la página de la memoria virtual que 
se ha asignado. 

Cuando el sistema carga una página P de la base de 
datos en memoria virtual, se realiza el rescate de pun¬ 
teros en la página: se buscan todos los punteros persis¬ 
tentes contenidos en los objetos de la página P utili¬ 
zando la información adicional guardada en la misma. 
Para cada puntero en la página se realizan las siguien¬ 
tes acciones (sea ( p ¡, el) el valor del puntero persisten¬ 
te, donde p¡ es el identificador de página corto y d¡ es el 
desplazamiento de la página, y sea P¡ el identificador de 
página completo de p¡, hallado en la tabla de traducción 
de la página P). 


4 El término página se usa normalmente para referirse a la página de 
memoria real o virtual, y el término bloque se usa para referirse a los 
bloques de disco de la base de datos. En el rescate hardware deben 
ser del mismo tamaño y los bloques de la base de datos se buscan 
en las páginas de la memoria virtual. Se usarán los términos página 
y bloque para significar lo mismo. 
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FIGURA 11.22. Imagen de una página antes del rescate. 


1. Si la página P¡ no tiene asignada todavía una pági¬ 
na de memoria virtual se le asignará ahora una 
página libre del espacio de las direcciones vir¬ 
tuales. La página P¡ residirá en la ubicación de la 
dirección virtual en el momento en que se lleve 
si esto se lleva a cabo. En este momento la pági¬ 
na del espacio de direcciones virtuales no tiene 
espacio de almacenamiento asignado, ni en la 
memoria ni en el disco; se trata simplemente de 
un rango de direcciones reservado para la página 
de la base de datos. El sistema asigna espacio real 
cuando realmente carga la página P¡ de la base de 
datos en memoria virtual. 

2. Sea v¡ la página de la memoria virtual asignada a 
P¡ (bien con anterioridad, bien en el paso ante¬ 
rior). El sistema actualiza el puntero persistente 


considerado, cuyo valor es ( p ¡, d¡), reemplazan¬ 
do p¡ por v¡. 

Después de actualizar todos los punteros persisten¬ 
tes, cada entrada (p¡, P¡) de la tabla de traducción se 
reemplaza por (v„ P¡), donde v¡ es la página de memo¬ 
ria virtual que se ha asignado para P¡. 

En la Figura 11.23 se muestra el estado de la página 
de la Figura 11.22 después de que se haya llevado a la 
memoria y se hayan rescatado sus punteros. Aquí se 
supone que la página cuyo identificador de página de la 
base de datos es 679.34278 se ha asociado con la pági¬ 
na 5001 de la memoria, mientras que la página cuyo 
identificador es 519.56850 se ha hecho corresponder con 
la página 4867 (que coincide con el identificador de pági¬ 
na corto). Todos los punteros de los objetos se han actua- 
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FIGURA 11.23. Imagen de la página después del rescate. 
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lizado para que reflejen la nueva asociación y pueden 
utilizarse como punteros internos de la memoria. 

Al final de la fase de traducción de cada página, los 
objetos de la misma cumplen una propiedad importan¬ 
te: todos los punteros persistentes contenidos en los 
objetos de esa página se han transformado en punteros 
internos de la memoria. Por tanto, los objetos de las 
páginas internas de la memoria sólo contienen punte¬ 
ros intemos de la memoria. Las ratinas que utilicen estos 
objetos ni siquiera tienen que conocer la existencia de 
los punteros persistentes. Por ejemplo, las bibliotecas 
existentes escritas para los objetos internos de la memo¬ 
ria pueden utilizarse sin modificación alguna para los 
objetos persistentes. Esto es una ventaja importante. 

11.9.4.3. Desreíerencia de punteros 

Considérese la primera vez que se desreferencia un pun¬ 
tero interno de la memoria de una página v, cuando toda¬ 
vía no se ha asignado espacio de almacenamiento para 
esa página. Como se ha descrito, tendrá lugar una vio¬ 
lación del encauzamiento y dará lugar a una llamada a 
una función en el sistema de bases de datos. El sistema 
de bases de datos realiza las siguientes acciones: 

1. En primer lugar determina la página de la base de 
datos que se asignó a la página de la memoria vir¬ 
tual v,; sea P¡ el identificador de página sin acor¬ 
tar de la página de la base de datos (si no hay nin¬ 
guna página de la base de datos asignada a v¡ se 
indicará la existencia de un error). 

2. Asigna espacio de almacenamiento para la página 
v, y se carga en ella la página P¡ de la base de datos. 

3. Realiza rescate de punteros en la página P¡, el sis¬ 
tema permite que continúe la desreferencia del 
puntero que resultó en la violación de segmenta¬ 
ción. La desreferencia del puntero encontrará car¬ 
gado en memoria el objeto que estaba buscando. 

Si cualquier puntero rescatado que apunte a un obje¬ 
to en la página v, se desreferencia más tarde, la desre¬ 
ferencia funciona igual que cualquier otro acceso a la 
memoria virtual, sin sobrecargas extra. En cambio, si 
no se usa el rescate, hay una considerable sobrecarga al 
localizar la página de la memoria intermedia que con¬ 
tiene el objeto y su posterior acceso. Esta sobrecarga 
aparece en cada acceso a los objetos de la página mien¬ 
tras que, cuando se usa el rescate, la sobrecarga sólo 
aparece en el primer acceso al objeto en la página. Los 
accesos posteriores funcionan a la velocidad normal de 
los accesos a memoria virtual. Por tanto, el rescate hard¬ 
ware proporciona excelentes beneficios de rendimien¬ 
to para aplicaciones que desreferencien punteros repe¬ 
tidamente. 

11.9.4.4. Optimizaciones 

El rescate software tiene una operación de devolución 
asociada, cuando hay que volver a escribir en la base 


de datos una página de la memoria, para transformar de 
nuevo los punteros internos de la memoria en persis¬ 
tentes. El rescate hardware puede incluso evitar este 
paso (cuando se realiza el rescate de punteros de la pági¬ 
na sencillamente se actualiza la tabla de traducción, por 
lo que la parte del identificador de página de los punte¬ 
ros internos de la memoria simulados puede utilizarse 
para buscar en la tabla). Por ejemplo, tal y como se 
muestra en la Figura 11.23, la página 679.34278 de la 
base de datos (con el identificador corto 2395 en la pági¬ 
na mostrada) se asocia con la página 5001 de la memo¬ 
ria virtual. En este momento no sólo se actualiza el pun¬ 
tero del objeto 1 de 2395255 a 5001255, sino que 
también se actualiza a 5001 el identificador corto de la 
tabla. Por tanto, el identificador corto 5001 del objeto 
1 y de la tabla vuelven a coincidir. Por consiguiente, se 
puede volver a escribir la página en el disco sin necesi¬ 
dad de devolverla. 

Se pueden llevar a cabo varias optimizaciones del 
esquema básico aquí mostrado. Cuando se realiza el res¬ 
cate de la página P, el sistema intenta asignar P' a la 
posición de dirección virtual indicada por el identifica¬ 
dor de página corto de P' de la página P. Si la página 
puede asignarse tal y como se ha intentado, no hay que 
actualizar los punteros que la apunten. En el ejemplo de 
rescate expuesto, la página 519.56850 con el identifi¬ 
cador de página corto 4867 se asoció con la página 4867 
de la memoria virtual, que coincide con su identifica¬ 
dor de página corto. Puede verse que no hay que modi¬ 
ficar el puntero del objeto 2 que apunta a esta página 
durante el rescate. Si puede asignarse cada página a su 
posición correcta en el espacio de las direcciones vir¬ 
tuales no habrá que transformar ninguno de los punte¬ 
ros y se reducirá de modo significativo el coste del res¬ 
cate. 

El rescate hardware funciona aunque la base de 
datos sea de mayor tamaño que la memoria virtual, 
pero sólo mientras todas las páginas a las que cada pro¬ 
ceso concreto tenga acceso quepan en la memoria vir¬ 
tual del mismo. Si no caben, habrá que sustituir las 
páginas llevadas a la memoria virtual, y esa sustitu¬ 
ción resulta difícil, dado que puede haber punteros 
internos de la memoria que apunten a objetos de esas 
páginas. También puede utilizarse teóricamente el res¬ 
cate hardware en el nivel de los conjuntos de páginas 
(a menudo denominados segmentos), en lugar de para 
páginas aisladas, siempre que los identificadores de 
página cortos, con los desplazamientos de página, no 
superen la memoria de los punteros internos de la 
memoria. 

El rescate hardware también se puede usar en el 
nivel de los conjuntos de páginas (a menudo deno¬ 
minados segmentos) en lugar de en una sola página. 
Para el rescate por conjuntos el sistema usa una úni¬ 
ca tabla de traducción para todas las páginas del seg¬ 
mento. Carga las páginas en el segmento y las resca¬ 
ta cuando es necesario; no es necesario que se carguen 
todas juntas. 
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11.9.5. Estructura de los objetos en el disco 
o en la memoria 

El formato con el que se guardan los objetos en la 
memoria puede ser diferente del formato con el que se 
guardan en el disco en la base de datos. Un motivo pue¬ 
de ser el uso del rescate software, en el que la estructu¬ 
ra de los punteros persistentes y la de los internos de la 
memoria son diferentes. Otro motivo puede ser que se 
desee hacer que la base de datos sea accesible desde 
diferentes máquinas, posiblemente basadas en arqui¬ 
tecturas diferentes, y desde lenguajes diferentes, y des¬ 
de programas compilados con compiladores diferentes, 
todo lo cual da lugar a diferencias en la representación 
en la memoria. 

Considérese, por ejemplo, la definición de una 
estructura de datos en un lenguaje de programación 
como C++. La estructura física (como los tamaños y la 
representación de los enteros) del objeto es dependiente 
de la máquina en la que se ejecuta el programa 5 . Ade¬ 
más, la estructura física puede depender también del 
compilador que se utilice; en un lenguaje tan comple¬ 
jo como C++ son posibles diferentes opciones para la 
traducción de la descripción de nivel superior a la 
estructura física, y cada compilador puede tomar sus 
propias opciones. 

La solución a este problema es hacer independiente 
de la máquina y del compilador la representación físi¬ 
ca de los objetos de la base de datos. Los objetos pue¬ 
den pasarse de la representación en el disco a las for¬ 
mas necesarias para la máquina, lenguaje y compilador 
concretos cuando se llevan a la memoria. Esta conver¬ 
sión puede hacerse de manera transparente al mismo 
tiempo que se rescatan los punteros del objeto, de modo 
que el programador no tenga que preocuparse por ella. 

El primer paso en la implementación de un esquema 
así es definir un lenguaje común para describir la estruc¬ 
tura de los objetos (es decir, un lenguaje para la defini¬ 
ción de datos). Se han realizado varias propuestas, una 
de las cuales es el lenguaje de definición de objetos 
(Object Definition Language, ODL) desarrollado por el 
grupo de gestión de bases de datos de objetos (Object 
Database Management Group, ODMG). ODL tiene defi¬ 
nidas asociaciones con Java, C++ y Smalltalk, por lo 
que en teoría los objetos de una base de datos que cum¬ 
pla ODMG se pueden tratar utilizando cualquiera de 
estos lenguajes. 

La definición de la estructura de cada clase de la base 
de datos se guarda (de manera lógica) en las bases de 


datos. El código para pasar los objetos de la base de 
datos a la representación de los mismos que trata el len¬ 
guaje de programación (y viceversa) es dependiente de 
la máquina y del compilador del lenguaje. Este código 
se puede generar de manera automática utilizando las 
definiciones de las clases de los objetos guardadas pre¬ 
viamente. 

Una fuente inesperada de diferencias entre las repre¬ 
sentaciones de los datos en el disco y en la memoria 
son los punteros ocultos de los objetos. Los punteros 
ocultos son punteros transitorios que generan los com¬ 
piladores y se guardan en los objetos. Estos punteros 
apuntan (de modo indirecto) a las tablas utilizadas para 
implementar ciertos métodos del objeto. Las tablas 
suelen compilarse en código objeto ejecutable y la ubi¬ 
cación exacta de las tablas depende del código obje¬ 
to ejecutable, por lo que puede ser diferente en pro¬ 
cesos diferentes. Por tanto, cuando un proceso tiene 
acceso a un objeto, los punteros ocultos deben fijarse 
para que apunten a la ubicación correcta. Los punte¬ 
ros ocultos pueden inicializarse al tiempo que se lle¬ 
van a cabo las conversiones entre las representacio¬ 
nes de los datos. 

11.9.6. Objetos de gran tamaño 

Los objetos pueden ser también enormemente grandes; 
por ejemplo, los objetos multimedia pueden ocupar 
varios megabytes. Los elementos de datos excepcio¬ 
nalmente grandes, como las secuencias de vídeo, pue¬ 
den llegar a los gigabytes, aunque suelen dividirse en 
varios objetos, cada uno de ellos del orden de unos pocos 
megabytes o menos. Los objetos de gran tamaño que 
contienen datos binarios se denominan objetos de gran 
tamaño en binario (binary large objects, blobs), mien¬ 
tras que los grandes objetos que contienen datos de 
caracteres se denominan objetos de gran tamaño de tipo 
carácter (character large objects, clobs), como se vio en 
el Apartado 9.2.1. 

La mayor parte de las bases de datos relaciónales 
limitan el tamaño de los registros para que no tengan 
una longitud mayor que el tamaño de la página para sim¬ 
plificar la gestión de la memoria intermedia y del espa¬ 
cio libre. Los objetos de gran tamaño y los campos lar¬ 
gos suelen guardarse en un archivo especial (o en un 
conjunto de archivos) reservado para el almacenamiento 
de campos largos. 

Se presenta un problema en la gestión de los objetos 
de gran tamaño con la asignación de las páginas de 


5 Por ejemplo, las arquitecturas Motorola 680x0, la arquitectura IBM 
360 y las arquitecturas Intel 80386/80486/Pentium/Pentium-II/Pen- 
tium-IIl tienen todas enteros de cuatro bytes. Sin embargo, se dife¬ 
rencian en la manera en que se disponen en las palabras los bits de 
los enteros. En las computadoras personales de las primeras gene¬ 
raciones los enteros tenían una longitud de dos bytes; en las arqui¬ 
tecturas de estaciones de trabajo más recientes, como la Alpha de 
Compaq, Itanium de Intel y UltraSparc de Sun, los enteros pueden 
tener una longitud de ocho bytes. 
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memoria intermedia. Los objetos de gran tamaño pue¬ 
den necesitar ser guardados en una secuencia contigua 
de bytes cuando se llevan a la memoria; en este caso, si 
un objeto es mayor que una página, se deben asignar 
páginas contiguas de la memoria intermedia para guar¬ 
darlo, lo que hace más difícil la gestión de la memoria 
intermedia. 

Los objetos de gran tamaño suelen modificarse actua¬ 
lizando una parte de los mismos o insertándoles o 
borrándoles alguna parte del objeto, en lugar de escri¬ 
biendo todo el objeto. Si hay que trabajar con insercio¬ 
nes o borrados, se pueden implementar los objetos de 
gran tamaño utilizando estructuras de árboles B (que se 
estudian en el Capítulo 12). Las estructuras de árboles 
B permiten leer todo el objeto, así como insertar y borrar 
partes del mismo. 

Por razones prácticas se pueden manipular los obje¬ 
tos de gran tamaño utilizando programas de aplicacio¬ 
nes en vez de hacerlo dentro de la base de datos: 

• Datos de texto. El texto suele tratarse como una 
cadena de bytes con la que trabajan los editores y 
los formateadores. 


• Datos gráficos. Los datos gráficos pueden repre¬ 
sentarse como mapas de bits o como conjuntos de 
líneas, cuadros y otros objetos geométricos. Aun¬ 
que algunos datos gráficos suelen tratarse dentro 
de la base de datos, en muchos casos se utiliza soft¬ 
ware de aplicaciones especiales, como en el dise¬ 
ño de circuitos integrados. 

• Datos de sonido y de vídeo. Los datos de sonido 
y de vídeo suelen ser una representación digitali¬ 
zada y comprimida creada y reproducida por soft¬ 
ware de aplicaciones diferentes. La modificación 
de los datos suele realizarse con software especial 
para ediciones, fuera del sistema de bases de datos. 

El método más utilizado para actualizar estos datos 
es el método desmarcar/marcar. El usuario o la apli¬ 
cación desmarca una copia de un objeto de campo lar¬ 
go, opera con esta copia utilizando programas especia¬ 
les de aplicaciones y luego marca la copia modificada. 
Los conceptos desmarcar y marcar se corresponden a 
grandes rasgos con los de lectura y escritura. En algu¬ 
nos sistemas, al marcar se puede crear una nueva ver¬ 
sión del objeto sin borrar la anterior. 


11.10. RESUMEN 


• En la mayor parte de los sistemas informáticos hay 
varios tipos de almacenamiento de datos. Estos medios 
de almacenamiento se clasifican según la velocidad 
con la que se puede tener acceso a los datos, el coste 
de adquisición de la memoria por unidad de datos y 
su fiabilidad. Entre los medios disponibles suelen estar 
la organización caché, la memoria principal, la memo¬ 
ria flash, los discos magnéticos, los discos ópticos y 
las cintas magnéticas. 

• La fiabilidad de los medios de almacenamiento se 
determina mediante dos factores: si un corte en el 
suministro eléctrico o una caída del sistema hace que 
los datos se pierdan, y la probabilidad de fallo físico 
del dispositivo de almacenamiento. 

• Se puede reducir la probabilidad del fallo físico con¬ 
servando varias copias de los datos. Para los discos 
se puede utilizar la creación de imágenes. También se 
pueden usar métodos más sofisticados como las dis¬ 
posiciones redundantes de discos independientes 
(RAID). La distribución de los datos entre los discos 
ofrece altos índices de productividad en los accesos 
de gran tamaño; introduciendo la redundancia entre 
los discos se mejora mucho la fiabilidad. Se han pro¬ 
puesto varias organizaciones RAID diferentes, con 
características de coste, rendimiento y fiabilidad dife¬ 
rentes. Las organizaciones RAID de nivel 1 (la crea¬ 
ción de imágenes) y RAID nivel 5 son las más utili¬ 
zadas. 


• Los archivos se pueden organizar lógicamente como 
una secuencia de registros asociados con bloques de 
disco. Un enfoque de la asociación de la base de datos 
con los archivos es utilizar varios archivos y guardar 
los registros de una única longitud fija en cualquier 
archivo dado. Una alternativa es estructurar los archi¬ 
vos de modo que puedan aceptar registros de longitud 
variable. Hay diferentes técnicas para la implementa- 
ción de los registros de longitud variable, incluyendo 
el método de la página con ranuras, el método de los 
punteros y el método del espacio reservado. 

• Dado que los datos se transfieren entre el almacena¬ 
miento en disco y la memoria principal en unidades 
de bloques, merece la pena asignar los registros de 
los archivos de modo que cada bloque contenga regis¬ 
tros relacionados. Si se puede tener acceso a varios 
de los registros deseados utilizando sólo un acceso a 
bloques se evitan accesos al disco. Dado que los acce¬ 
sos al disco suelen ser el cuello de botella del rendi¬ 
miento de los sistemas de bases de datos, la esmera¬ 
da asignación de los registros a los bloques puede 
ofrecer mejoras significativas del rendimiento. 

• Una manera de reducir el número de accesos al disco 
es guardar todos los bloques posibles en la memoria 
principal. Dado que no se pueden guardar todos los 
bloques en la memoria principal, hay que gestionar la 
asignación del espacio disponible en la memoria prin¬ 
cipal para el almacenamiento de los bloques. La 
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memoria intermedia ( buffer ) es la parte de la memo¬ 
ria disponible para el almacenamiento de las copias 
de los bloques del disco. El subsistema responsable de 
la asignación del espacio de la memoria intermedia se 
denomina gestor de la memoria intermedia. 

• Los sistemas de almacenamiento para las bases de datos 
orientadas a objetos son algo diferentes de los sistemas 
de almacenamiento para las bases de datos relacióna¬ 
les: deben trabajar con objetos de gran tamaño, por 


ejemplo, y con punteros persistentes. Hay esquemas 
para detectar los punteros persistentes colgantes. 

• Los esquemas de rescate software y hardware permi¬ 
ten la desreferencia eficiente de los punteros persis¬ 
tentes. Los esquemas basados en hardware utilizan el 
apoyo a la gestión de la memoria virtual realizado en 
hardware y muchos sistemas operativos de la gene¬ 
ración actual los hacen accesibles a los programas del 
usuario. 


TÉRMINOS DE REPASO 


• Almacenamiento terciario 

— Discos ópticos 

— Cintas magnéticas 

— Cambiadores automáticos 

• Archivo 

• Bloque de disco 

• Catálogo del sistema 

• Clave de búsqueda 

• Diccionario de datos 

• Disco magnético 

— Plato 

— Discos rígidos 

— Disquetes 

— Pistas 

— Sectores 

— Cabeza de lectura y escritura 

— Brazo del disco 

— Cilindro 

— Controlador de discos 

— Comprobación de suma 

— Reasignación de sectores defectuosos 

• Disposición redundante de discos independientes 
(RAID) 

— Creación de imágenes 

— Distribución de datos 

— Distribución en el nivel de bit 

— Distribución en el nivel de bloque 

• Estructuras de almacenamiento para BDOO 

• Identificador del objeto (IDO) 

— IDO lógico 

— IDO físico 

— Identificador único 

— Puntero colgante 

— Dirección de entrega 

• Intercambio en caliente 


Medidas de rendimiento de los discos 

— Tiempo de acceso 

— Tiempo de búsqueda 

— Latencia rotacional 

— Velocidad de transferencia de datos 

— Tiempo medio entre fallos 
Medios de almacenamiento físico 

— Caché 

— Memoria principal 

— Memoria flash 

— Disco magnético 

— Almacenamiento óptico 
Memoria intermedia (buffer) 

— Gestor de la memoria intermedia 

— Bloques clavados 

— Salida forzada de bloques 
Niveles de RAI D 

— Nivel 0 (distribución de bloques sin redundancia) 

— Nivel 1 (distribución de bloques con creación de 
imágenes) 

— Nivel 3 (distribución de bits con paridad) 

— Nivel 5 (distribución de bloques con paridad dis¬ 
tribuida) 

— Nivel 6 (distribución de bloques con redundancia 
P + Q) 

Objetos de gran tamaño 

Optimización del acceso a bloques de disco 

— Planificación del brazo 

— Algoritmo del ascensor 

— Organización de archivos 

— Desfragmentación 

— Memorias intermedias de escritura no volátiles 

— Memoria no volátil de acceso aleatorio 

— Disco del registro histórico 

— Sistema de archivos basado en registro histórico 
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• Organización asociativa (hash) de archivos 

• Organización de archivos 

— Lista libre 

• Organización de archivos en agrupaciones 

• Organización de archivos en montículo 

• Organización de archivos secuenciales 

• Políticas de sustitución de la memoria intermedia 

— Menos recientemente utilizado (Least Recently 
Used, LRU) 

— Extracción inmediata 

— Más recientemente utilizado (Most Recently Used, 
MRU) 

• Punteros ocultos 

• RAID hardware 

• RAID software 


• Registros de longitud fija 

— Representación en cadenas de bytes 
— Estructura de páginas con ranuras 
— Espacio reservado 
— Representación de listas 

• Registros de longitud variable 
— Cabecera del archivo 

— Lista libre 

• Rendimiento de la reconstrucción 

• Rescate de punteros 
— Desreferencia 
— Devolución 

— Rescate software 
— Rescate hardware 
— Violación de la segmentación 
— Fallo de página 


EJERCICIOS 


11.1. Indíquense los medios de almacenamiento físico dis¬ 
ponibles en las computadoras que se utilizan habitual¬ 
mente. Dese la velocidad con la que se puede tener acce¬ 
so a los datos en cada medio. 

11.2. ¿Cómo afecta la reasignación de los sectores dañados 
por los controladores de disco a la velocidad de recu¬ 
peración de los datos? 

11.3. Considérese la siguiente disposición de los bloques de 
datos y de paridad de cuatro discos: 


Disco 1 

Disco 2 

Disco 3 

Disco 4 

S, 

e 2 

e 3 

s 4 

Si 

s 5 

e 6 

e 7 

S 8 

S 2 

s 9 

*10 


B¡ representa los bloques de datos; P¡, los bloques de 
paridad. El bloque de paridad P¡ es el bloque de pari¬ 
dad para los bloques de datos B 4i _ 3 a B 4¡ . Indíquense los 
problemas que puede presentar esta disposición. 

11.4. Un fallo en el suministro eléctrico que se produzca 
mientras se escribe un bloque del disco puede dar lugar 
a que el bloque sólo se escriba parcialmente. Supón¬ 
gase que se pueden detectar los bloques escritos par¬ 
cialmente. Un proceso atómico de escritura de bloque 
es aquel en el que se escribe el bloque entero o no se 
escribe nada (es decir, no hay procesos de escritura par¬ 
ciales). Propónganse esquemas para conseguir el efec¬ 
to de los procesos atómicos de escritura con los siguien¬ 
tes esquemas RAID. Los esquemas deben implicar 
procesos de recuperación de fallos. 

a. RAID de nivel 1 (creación de imágenes) 

b. RAID de nivel 5 (entrelazado de bloques, paridad 
distribuida) 


11.5. Los sistemas RAID suelen permitir la sustitución de 
los discos averiados sin que se impida el acceso al sis¬ 
tema. Por tanto, los datos del disco averiado deben 
reconstruirse y escribirse en el disco de repuesto mien¬ 
tras el sistema se halla en funcionamiento. ¿Con cuál 
de los niveles RAID es menor la interferencia entre los 
accesos al disco reconstruido y los accesos al resto de 
los discos? Justifiqúese la respuesta. 

11.6. Dese un ejemplo de una expresión de álgebra relacio- 
nal y de una estrategia de procesamiento de consultas 
en cada una de las situaciones siguientes: 

a. MRU es preferible a LRU. 

b. LRU es preferible a MRU. 

11.7. Considérese el borrado del registro 5 del archivo de la 
Figura 11.8. Compárense las ventajas relativas de las 
siguientes técnicas para implementar el borrado: 

a. Trasladar el registro 6 al espacio ocupado por el 
registro 5 y desplazar el registro 7 al espacio ocu¬ 
pado por el registro 6. 

b. Trasladar el registro 7 al espacio ocupado por el 
registro 5. 

c. Marcar el registro 5 como borrado y no desplazar 
ningún registro. 

11.8. Muéstrese la estructura del archivo de la Figura 11.9 
después de cada uno de los pasos siguientes: 

a. Insertar (C-323, Galapagar, 1600). 

b. Borrar el registro 2. 

c. Insertar (C-626, Galapagar, 2000). 

11.9. Dese un ejemplo de una aplicación de bases de datos 
en que sea preferible el método del espacio reservado 
para la representación de los registros de longitud va¬ 
riable frente al método de los punteros. Justifiqúese la 
respuesta. 
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11.10. Dese un ejemplo de una aplicación de bases de datos 
en la que sea preferible el método de los punteros para 
representar los registros de longitud variable al méto¬ 
do del espacio reservado. Justifiqúese la respuesta. 

11.11. Muéstrese la estructura del archivo de la Figura 11.12 
después de cada uno de los pasos siguientes: 

a. InsertFar (C-101, Becerril, 2800). 

b. Insertar (C-323, Galapagar, 1600). 

c. Borrar (C-102, Navacerrada, 400). 

11.12. ¿Qué ocurre si se intenta insertar el registro 

(C-929, Navacerrada, 3000) 
en el archivo de la Figura 11.12? 

11.13. Muéstrese la estructura del archivo de la Figura 11.13 
después de cada uno de los pasos siguientes: 

a. Insertar (C-101, Becerril, 560.000). 

b. Insertar (C-323, Galapagar, 320.000). 

c. Borrar (C-102, Navacerrada, 80.000). 

11.14. Expliqúese por qué la asignación de los registros a los 
bloques afecta de manera significativa al rendimien¬ 
to de los sistemas de bases de datos. 

11.15. Si es posible, determínese la estrategia de gestión de 
la memoria intermedia de su sistema operativo eje¬ 
cutándose en su computadora y los mecanismos que 
proporciona para controlar la sustitución de páginas. 
Discútase cómo el control sobre la sustitución que pro¬ 
porciona podría ser útil para la implementación de sis¬ 
temas de bases de datos. 

11.16. En la organización secuencial de los archivos, ¿por 
qué se utiliza un bloque de desbordamiento aunque 
sólo haya en ese momento un único registro de des¬ 
bordamiento? 

11.17. Indíquense dos ventajas y dos inconvenientes de cada 
una de las estrategias siguientes para el almacena¬ 
miento de bases de datos relaciónales: 

a. Guardar cada relación en un archivo. 

b. Guardar varias relaciones (quizá toda la base de 
datos) en un archivo. 

11.18. Considérese una base de datos relacional con dos rela¬ 
ciones: 


curso ( nombre-curso, aula, profesor) 

matrícula ( nombre-curso , nombre-estudiante, nivel) 

Defínanse ejemplos de estas relaciones para tres cur¬ 
sos, en cada uno de los cuales se matriculan cinco estu¬ 
diantes. Dese una estructura de archivos de estas rela¬ 
ciones que utilice la agrupación. 

11.19. Considérese la siguiente técnica de mapa de bits para 
realizar el seguimiento del espacio libre de un archivo. 
Por cada bloque del archivo se mantienen dos bits en 
el mapa. Si el bloque está lleno entre el 0 y el 30 por 
ciento, los bits son 00, entre 30 por ciento y 60 por cien¬ 
to, 01, entre 60 por ciento y 90 por ciento, 10, y por 
encima de 90 por ciento, 11. Tales mapas se pueden 
mantener en memoria incluso para grandes archivos. 

a. Descríbase cómo mantener actualizado el mapa de 
bits al insertar y eliminar registros. 

b. Descríbanse el beneficio de la técnica de los mapas 
de bits sobre las listas libres al buscar espacio libre 
y al actualizar su información. 

11.20. Dese una versión normalizada de la relación Meta- 
datos-índices y expliqúese por qué al usar la versión 
normalizada se incurriría en pérdida de rendimiento. 

11.21. Expliqúese el motivo de que un IDO físico deba con¬ 
tener más información que un puntero que apunte a 
una ubicación física de almacenamiento. 

11.22. Si se utilizan IDOs físicos, un objeto se puede reubi¬ 
car guardando un puntero a su nueva ubicación. En el 
caso de que se guarden varios punteros para un obje¬ 
to, ¿cuál sería el efecto sobre la velocidad de recupe¬ 
ración? 

11.23. Defínase el término puntero colgante. Descríbase la 
manera en que el esquema de identificador único ayu¬ 
da a detectar los punteros colgantes en las bases de 
datos orientadas a objetos. 

11.24. Considérese el ejemplo de la página 276, que mues¬ 
tra que no hace falta el rescate si se utiliza el rescate 
hardware. Expliqúese el motivo de que, en ese ejem¬ 
plo, resulte seguro cambiar el identificador corto de 
la página 679.34278 de 2395 a 5001. ¿Puede tener ya 
alguna otra página el identificador corto 5001? Si fue¬ 
ra así, ¿cómo se resolvería esa situación? 


NOTAS BIBLIOGRÁFICAS 


Patterson y Hennessy [1995] discuten los aspectos de 
hardware de la memoria intermedia con traducción anti¬ 
cipada, de las cachés y de las unidades de gestión de la 
memoria. Rosch y Wethington [1999] presentan una 
excelente visión general del hardware de computadoras, 
incluyendo un tratamiento extensivo de todos los tipos 
de tecnologías de almacenamiento como disquetes, dis¬ 
cos magnéticos, discos ópticos, cintas e interfaces de 
almacenamiento. Ruemmler y Wilkes [1994] presentan 
una revisión de lo tecnología de los discos magnéticos. 
La memoria flash se discute en Dippert y Levy [1993]. 


Las especificaciones de las unidades de disco actua¬ 
les se pueden obtener de los sitios Web de sus fabri¬ 
cantes, como IBM, Seagate y Maxtor. 

Las organizaciones alternativas de los discos que pro¬ 
porcionan un elevado grado de tolerancia a los fallos 
incluyen las desarrolladas por Gray et al. [1990] y por 
Bitton y Gray [1988]. La distribución en los discos se 
describe en Salem y García-Molina [1986]. Se presen¬ 
tan discusiones sobre las disposiciones redundantes de 
discos independientes (RAID) en Patterson et al. [1988] 
y en Chen y Patterson [1990]. Chen et al. [1994] pre- 
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sentan una excelente revisión de los principios y de la 
aplicación de RAID. Los códigos de Reed-Solomon se 
tratan en Pless [1989]. El sistema de archivos basado 
en registro histórico, que hace secuencial el acceso a 
disco, se describe en Rosenblum y Ousterhout [1991]. 

En los sistemas que permiten la informática portátil 
se pueden transmitir los datos de manera reiterada. El 
medio de transmisión puede considerarse un nivel de la 
jerarquía de almacenamiento (como un disco transmi¬ 
sor con latencia elevada). Estos aspectos se discuten en 
Acharya et al. [1995]. La gestión de la caché y de las 
memorias intermedias en la informática portátil se dis¬ 
cute en Barbará e Imielinski [1994]. En Douglis et al. 
[1994] aparecen más discusiones de los problemas de 
almacenamiento en la informática portátil. 

Las estructuras de datos básicas se discuten en Cor- 
men et al. [1990]. Hay varios artículos que describen la 
estructura de almacenamiento de sistemas específicos 
de bases de datos. Astrahan et al. [1976] y System 
R. Chamberlin et al. [1981] repasan en retrospectiva, 
System R. Oracle 8 Concepts Manual (Oracle [1997]) 
describe la organización de almacenamiento del siste¬ 
ma de bases de datos Oracle 8. La estructura de Wis- 
consin Storage System (WiSS) se describe en Chou et 
al. [1985]. En Finkelstein et al. [1988] se describe una 
herramienta de software para el diseño físico de bases 
de datos relaciónales. 


La gestión de las memorias intermedias se discute 
en la mayor parte de los textos sobre sistemas operati¬ 
vos, incluido Silberschatz y Galvin [1994]. Stonebra- 
ker [1981] discute la relación entre los gestores de 
memoria intermedia de los sistemas de bases de datos 
y los de los sistemas operativos. Chou y DeWitt [1985] 
presentan algoritmos para la gestión de memoria inter¬ 
media en sistemas de bases de datos y describe un méto¬ 
do de medida del rendimiento. Bridge et al. [1997] des¬ 
criben técnicas usadas en el gestor de la memoria 
intermedia del sistema de bases de datos Oracle. 

En Wilson [1990], Moss [1990] y White y DeWitt 
[1992] se ofrecen descripciones y comparaciones del 
rendimiento de diferentes técnicas de rescate. White y 
DeWitt [1994] describen el esquema de gestión de 
memoria intermedia asociado con la memoria virtual 
utilizado en el sistema ObjectStore OODB y en el ges¬ 
tor de almacenamiento QuickStore. Utilizando este 
esquema se pueden asociar las páginas del disco con 
direcciones fijas de la memoria virtual, aunque no estén 
clavadas en la memoria intermedia. El gestor de alma¬ 
cenamiento de objetos Exodus se describe en Carey et 
al. [1986]. Biliris y Orenstein [1994] proporcionan una 
revisión de los sistemas de almacenamiento para bases 
de datos orientadas a objetos. Jagadish et al. [1994] des¬ 
criben un gestor de almacenamiento para bases de datos 
en memoria principal. 
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INDEXACIÓN Y ASOCIACIÓN 


M uchas consultas hacen referencia sólo a una pequeña parte de los registros de un archi¬ 
vo. Por ejemplo, la pregunta «Buscar todas las cuentas de la sucursal Pamplona» o 
«Buscar el saldo del número de cuenta C-101» hace referencia solamente a una frac¬ 
ción de los registros de la relación cuenta. No es eficiente para el sistema tener que leer cada 
registro y comprobar que el campo nombre-sucursal contiene el nombre «Pamplona» o el valor 
C-101 del campo número-cuenta. Lo más adecuado sería que el sistema fuese capaz de locali¬ 
zar directamente estos registros. Para facilitar estas formas de acceso se diseñan estructuras adi¬ 
cionales que se asocian con archivos. 


12.1. CONCEPTOS BÁSICOS 


Un índice para un archivo del sistema funciona como 
el índice de este libro. Si se va a buscar un tema (espe¬ 
cificado por una palabra o una frase) en este libro, se 
puede buscar en el índice al final del libro, encontrar las 
páginas en las que aparece y después leer esas páginas 
para encontrar la información que estamos buscando. 
Las palabras de índice están ordenadas, lo que hace fácil 
la búsqueda del término que se esté buscando. Además, 
el índice es mucho más pequeño que el libro, con lo que 
se reduce aún más el esfuerzo necesario para encontrar 
las palabras en cuestión. 

Los catálogos de fichas en las bibliotecas funcionan 
de manera similar (aunque se usan poco). Para encon¬ 
trar un libro de un autor en particular, se buscaría en el 
catálogo de autores y una ficha de este catálogo indica¬ 
ría dónde encontrar el libro. Para ayudarnos en la bús¬ 
queda en el catálogo, la biblioteca guardaría en orden 
alfabético las fichas de los autores con una ficha por 
cada autor de cada libro. 

Los índices de los sistemas de bases de datos juegan 
el mismo papel que los índices de los libros o los catá¬ 
logos de fichas de las bibliotecas. Por ejemplo, para 
recuperar un registro cuenta dado su número de cuen¬ 
ta, el sistema de bases de datos buscaría en un índice 
para encontrar el bloque de disco en que se encuentra 
el registro correspondiente, y entonces extraería ese blo¬ 
que de disco para obtener el registro cuenta. 

Almacenar una lista ordenada de números de cuen¬ 
ta no funcionaría bien en bases de datos muy grandes 
con millones de cuentas, ya que el propio índice sería 
muy grande; más aún, incluso al mantener ordenado el 
índice se reduce el tiempo de búsqueda, encontrar una 
cuenta puede consumir mucho tiempo. En su lugar se 
usan técnicas más sofisticadas de indexación. Algunas 
de estas técnicas se discutirán más adelante. 

Hay dos tipos básicos de índices: 


• índices ordenados. Estos índices están basados 
en una disposición ordenada de los valores. 

• índices asociativos (hash indices). Estos índices 
están basados en una distribución uniforme de los 
valores a través de una serie de cajones ( buckets). 
El valor asignado a cada cajón está determinado 
por una función, llamada función de asociación 
(hash fuñe don). 

Se considerarán varias técnicas de indexación y aso¬ 
ciación. Ninguna de ellas es la mejor. Sin embargo, cada 
técnica es la más apropiada para una aplicación especí¬ 
fica de bases de datos. Cada técnica debe ser valorada 
según los siguientes criterios: 

• Tipos de acceso. Los tipos de acceso que se 
soportan eficazmente. Estos tipos podrían incluir 
la búsqueda de registros con un valor concreto 
en un atributo, o buscar los registros cuyos atri¬ 
butos contengan valores en un rango especifi¬ 
cado. 

• Tiempo de acceso. El tiempo que se tarda en bus¬ 
car un determinado elemento de datos, o conjun¬ 
to de elementos, usando la técnica en cuestión. 

• Tiempo de inserción. El tiempo empleado en 
insertar un nuevo elemento de datos. Este valor 
incluye el tiempo utilizado en buscar el lugar apro¬ 
piado donde insertar el nuevo elemento de datos, 
así como el tiempo empleado en actualizar la 
estructura del índice. 

• Tiempo de borrado. El tiempo empleado en borrar 
un elemento de datos. Este valor incluye el tiem¬ 
po utilizado en buscar el elemento a borrar, así 
como el tiempo empleado en actualizar la estruc¬ 
tura del índice. 
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• Espacio adicional requerido. El espacio adi¬ 
cional ocupado por la estructura del índice. Como 
normalmente la cantidad necesaria de espacio 
adicional suele ser moderada, es razonable sacri¬ 
ficar el espacio para alcanzar un rendimiento 
mejor. 

A menudo se desea tener más de un índice por archi¬ 
vo. Volviendo al ejemplo de la biblioteca, nos damos 
cuenta de que la mayoría de las bibliotecas mantienen 


varios catálogos de fichas: por autor, por materia y por 
título. 

Los atributos o conjunto de atributos usados para bus¬ 
car en un archivo se llaman claves de búsqueda. Hay 
que observar que esta definición de clave difiere de la 
usada en clave primaria, clave candidata y superclave. 
Este doble significado de clave está (por desgracia) muy 
extendido en la práctica. Usando nuestro concepto de 
clave de búsqueda vemos que, si hay varios índices en 
un archivo, existirán varias claves de búsqueda. 


12.2. ÍNDICES ORDENADOS 


Para permitir un acceso directo rápido a los registros de 
un archivo se puede usar una estructura de índice. Cada 
estructura de índice está asociada con una clave de bús¬ 
queda concreta. Al igual que en el catálogo de una biblio¬ 
teca, un índice almacena de manera ordenada los valo¬ 
res de las claves de búsqueda, y asocia a cada clave los 
registros que contienen esa clave de búsqueda. 

Los registros en el archivo indexado pueden estar a 
su vez almacenados siguiendo un orden, semejante a 
como los libros están ordenados en una biblioteca por 
algún atributo como el número decimal Dewey. Un 
archivo puede tener varios índices según diferentes cla¬ 
ves de búsqueda. Si el archivo que contiene los regis¬ 
tros está ordenado secuencialmente, el índice cuya cla¬ 
ve de búsqueda especifica el orden secuencial del 
archivo es el índice primario. (El término índice pri¬ 
mario se emplea algunas veces para hacer alusión a un 
índice según una clave primaria. Sin embargo, tal uso 
no es normal y debería evitarse.) Los índices primarios 
también se llaman índices con agrupación ( clustering 
indices.) La clave de búsqueda de un índice primario es 


normalmente la clave primaria, aunque no es así ne¬ 
cesariamente. Los índices cuyas claves de búsqueda 
especifican un orden diferente del orden secuencial del 
archivo se llaman índices secundarios o índices sin 
agrupación ( non clustering indices). 

12.2.1. índice primario 

En este apartado se asume que todos los archivos están 
ordenados secuencialmente según alguna clave de bús¬ 
queda. Estos archivos con índice primario según una 
clave de búsqueda se llaman archivos secuenciales 
indexados. Representan uno de los esquemas de índi¬ 
ces más antiguos usados por los sistemas de bases de 
datos. Se emplean en aquellas aplicaciones que deman¬ 
dan un procesamiento secuencial del archivo completo 
así como un acceso directo a sus registros. 

En la Figura 12.1 se muestra un archivo secuencial de 
los registros cuenta tomados del ejemplo bancario. En esta 
figura, los registros están almacenados según el orden de 
la clave de búsqueda, siendo esta clave nombre-sucursal. 
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FIGURA 12.1. Archivo secuencial para los registros cuenta. 
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FIGURA 12.2. índice denso. 


12.2.1.1. Indices densos y dispersos 

Un registro índice o entrada del índice consiste en un 
valor de la clave de búsqueda y punteros a uno o más 
registros con ese valor de la clave de búsqueda. El pun¬ 
tero a un registro consiste en el identiñcador de un blo¬ 
que de disco y un desplazamiento en el bloque de dis¬ 
co para identificar el registro dentro del bloque. 

Hay dos clases de índices ordenados que se pueden 
emplear: 

• índice denso. Aparece un registro índice por cada 
valor de la clave de búsqueda en el archivo. El 
registro índice contiene el valor de la clave y un 
puntero al primer registro con ese valor de la cla¬ 
ve de búsqueda. El resto de registros con el mis¬ 
mo valor de la clave de búsqueda se almacenan 
consecutivamente después del primer registro, dado 
que, ya que el índice es primario, los registros se 
ordenan sobre la misma clave de búsqueda. 


Las implementaciones de índices densos pueden 
almacenar una lista de punteros a todos los regis¬ 
tros con el mismo valor de la clave de búsqueda; 
esto no es esencial para los índices primarios. 

• índice disperso. Sólo se crea un registro índice 
para algunos de los valores. Al igual que en los 
índices densos, cada registro índice contiene un 
valor de la clave de búsqueda y un puntero al pri¬ 
mer registro con ese valor de la clave. Para loca¬ 
lizar un registro se busca la entrada del índice con 
el valor más grande que sea menor o igual que el 
valor que se está buscando. Se empieza por el regis¬ 
tro apuntado por esa entrada del índice y se conti¬ 
núa con los punteros del archivo hasta encontrar 
el registro deseado. 

Las Figuras 12.2 y 12.3 son ejemplos de índices den¬ 
sos y dispersos, respectivamente, para el archivo cuen¬ 
ta. Supongamos que se desea buscar los registros de la 
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FIGURA 12.3. índice disperso. 
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sucursal Pamplona. Mediante el índice denso de la Figu¬ 
ra 12.2, se sigue el puntero que va directo al primer 
registro de Pamplona. Se procesa el registro y se sigue 
el puntero en ese registro hasta localizar el siguiente 
registro según el orden de la clave de búsqueda ( nom¬ 
bre-sucursal]). Se continuaría procesando registros has¬ 
ta encontrar uno cuyo nombre de sucursal fuese distin¬ 
to de Pamplona. Si se usa un índice disperso (Figura 
12.3), no se encontraría entrada del índice para «Pam¬ 
plona». Como la última entrada (en orden alfabético) 
antes de «Pamplona» es «Madrid», se sigue ese punte¬ 
ro. Entonces se lee el archivo cuenta en orden secuen- 
cial hasta encontrar el primer registro Pamplona, y se 
continúa procesando desde este punto. 

Como se ha visto, generalmente es más rápido loca¬ 
lizar un registro si se usa un índice denso en vez de un 
índice disperso. Sin embargo, los índices dispersos tie¬ 
nen algunas ventajas sobre los índices densos, como el 
utilizar un espacio más reducido y un mantenimiento 
adicional menor para las inserciones y borrados. 

Existe un compromiso que el diseñador del sistema 
debe mantener entre el tiempo de acceso y el espacio adi¬ 
cional requerido. Aunque la decisión sobre este compro¬ 
miso depende de la aplicación en particular, un buen com¬ 
promiso es tener un índice disperso con una entrada del 
índice por cada bloque. La razón por la cual este diseño 
alcanza un buen compromiso reside en que el mayor cos¬ 
te de procesar una petición en la base de datos pertenece 
al tiempo empleado en traer un bloque de disco a la 
memoria. Una vez traído el bloque, el tiempo en exami¬ 
nar el bloque completo es despreciable. Usando este índi¬ 
ce disperso se localiza el bloque que contiene el registro 
solicitado. De este manera, a menos que el registro esté 
en un bloque de desbordamiento (véase el Apartado 
11.7.1) se minimizan los accesos a bloques mientras man¬ 
tenemos el tamaño del índice (y así, nuestro espacio adi¬ 
cional requerido) tan pequeño como sea posible. 

Para generalizar la técnica anterior hay que tener en 
cuenta cuando los registros de una clave de búsqueda 
ocupan varios bloques. Es fácil modificar el esquema 
para acomodarse a esta situación. 

12.2.1.2. índices multinivel 

Incluso si se usan índices dispersos, el propio índice 
podría ser demasiado grande para un procesamiento efi¬ 
ciente. En la práctica no es excesivo tener un archivo 
con 100.000 registros, con 10 registros almacenados en 
cada bloque. Si tenemos un registro índice por cada blo¬ 
que, el índice tendrá 10.000 registros. Como los regis¬ 
tros índices son más pequeños que los registros de datos, 
podemos suponer que caben 100 registros índices en un 
bloque. Por tanto, el índice ocuparía 100 bloques. Estos 
índices de mayor tamaño se almacenan como archivos 
secuenciales en disco. 

Si un índice es lo bastante pequeño como para guar¬ 
darlo en la memoria principal, el tiempo de búsqueda 
para encontrar una entrada será breve. Sin embargo, si 


el índice es tan grande que se debe guardar en disco, 
buscar una entrada implicará leer varios bloques de dis¬ 
co. Para localizar una entrada en el archivo índice se 
puede realizar una búsqueda binaria, pero aun así ésta 
conlleva un gran coste. Si el índice ocupa b bloques, la 
búsqueda binaria tendrá que leer a lo sumo riog 2 (^)l 
bloques. ( [x~\ denota al menor entero que es mayor o 
igual ai; es decir, se redondea hacia abajo.) Para el índi¬ 
ce de 100 bloques, la búsqueda binaria necesitará leer 
siete bloques. En un disco en el que la lectura de un blo¬ 
que tarda 30 milisegundos, la búsqueda empleará 210 
milisegundos, lo que es mucho. Obsérvese que si se están 
usando bloques de desbordamiento, la búsqueda bina¬ 
ria no sería posible. En ese caso, lo normal es una bús¬ 
queda secuencial, y eso requiere leer b bloques, lo que 
podría consumir incluso más tiempo. Así, el proceso de 
buscar en un índice grande puede ser muy costoso. 

Para resolver este problema se trata el índice como 
si fuese un archivo secuencial y se construye un índice 
disperso sobre el índice primario, como se muestra en 
la Figura 12.4. Para localizar un registro se usa en pri¬ 
mer lugar una búsqueda binaria sobre el índice más 
externo para buscar el registro con el mayor valor de la 
clave de búsqueda que sea menor o igual al valor dese¬ 
ado. El puntero apunta a un bloque en el índice más 
interno. Hay que examinar este bloque hasta encontrar 
el registro con el mayor valor de la clave que sea menor 
o igual que el valor deseado. El puntero de este regis¬ 
tro apunta al bloque del archivo que contiene el regis¬ 
tro buscado. 

Usando los dos niveles de indexación y con el índi¬ 
ce más extemo en memoria principal, tenemos que leer 
un único bloque índice en vez de los siete que se leían 
con la búsqueda binaria. Si al archivo es extremada¬ 
mente grande, incluso el índice exterior podría crecer 
demasiado para caber en la memoria principal. En este 
caso se podría crear todavía otro nivel más de indexa¬ 
ción. De hecho, se podría repetir este proceso tantas 
veces como fuese necesario. Los índices con dos o más 
niveles se llaman índices multinivel. La búsqueda de 
registros usando un índice multinivel necesita clara¬ 
mente menos operaciones de E/S que las que se emple¬ 
an en la búsqueda de registros con la búsqueda binaria. 
Cada nivel de índice se podría corresponder con una 
unidad del almacenamiento físico. Así, podríamos tener 
índices a nivel de pista, cilindro o disco. 

Un diccionario normal es un ejemplo de un índice 
multinivel en el mundo ajeno a las bases de datos. La 
cabecera de cada página lista la primera palabra en el 
orden alfabético en esa página. Este índice es multini¬ 
vel: las palabras en la parte superior de la página del 
índice del libro forman un índice disperso sobre los con¬ 
tenidos de las páginas del diccionario. 

Los índices multinivel están estrechamente rela¬ 
cionados con la estructura de árbol, tales como los árbo¬ 
les binarios usados para la indexación en memoria. 
Examinaremos esta relación posteriormente en el Apar¬ 
tado 12.3. 
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FIGURA 12.4. índice disperso de dos niveles. 


12.2.1.3. Actualización del índice 

Sin importar el tipo de índice que se esté usando, los 
índices se deben actualizar siempre que se inserte o 
borre un registro del archivo. A continuación se des¬ 
cribirán los algoritmos para actualizar índices de un 
solo nivel. 

• Inserción. Primero se realiza una búsqueda usan¬ 
do el valor de la clave de búsqueda del registro a 
insertar. Las acciones que emprende el sistema a 
continuación dependen de si el índice es denso o 
disperso. 

- índices densos: 

1. Si el valor de la clave de búsqueda no apa¬ 
rece en el índice, el sistema inserta en éste 
un registro índice con el valor de la clave de 
búsqueda en la posición adecuada. 

2. En caso contrario se emprenden las siguien¬ 
tes acciones: 


a. Si el registro índice almacena punteros a 
todos los registros con el mismo valor de 
la clave de búsqueda, el sistema añade un 
puntero al nuevo registro en el registro 
índice. 

b. En caso contrario, el registro índice alma¬ 
cena un puntero sólo hacia el primer 
registro con el valor de la clave de bús¬ 
queda. El sistema sitúa el registro inser¬ 
tado después de los otros con los mismos 
valores de la clave de búsqueda. 

- índices dispersos: se asume que el índice alma¬ 
cena una entrada por cada bloque. Si el siste¬ 
ma crea un bloque nuevo, inserta el primer 
valor de la clave de búsqueda (en el orden de 
la clave de búsqueda) que aparezca en el nue¬ 
vo bloque del índice. Por otra parte, si el nue¬ 
vo registro tiene el menor valor de la clave de 
búsqueda en su bloque, el sistema actualiza la 
entrada del índice que apunta al bloque; si no, 
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el sistema no realiza ningún cambio sobre el 

índice. 

• Borrado. Para borrar un registro, primero se bus¬ 
ca el índice a borrar. De nuevo, las acciones que 
emprende el sistema a continuación dependen de 
si el índice es denso o disperso. 

- índices densos: 

1. Si el registro borrado era el único registro 
con ese valor de la clave de búsqueda, el sis¬ 
tema borra el registro índice correspondien¬ 
te del índice. 

2. En caso contrario se emprenden las siguien¬ 
tes acciones: 

a. Si el registro índice almacena punteros a 
todos los registros con el mismo valor de 
la clave de búsqueda, el sistema borra del 
registro índice el puntero al registro bo¬ 
rrado. 

b. En caso contrario, el registro índice alma¬ 
cena un puntero sólo al primer registro 
con el valor de la clave de búsqueda. En 
este caso, si el registro borrado era el pri¬ 
mer registro con el valor de la clave de 
búsqueda, el sistema actualiza el registro 
índice para apuntar al siguiente registro. 

- índices dispersos: 

1. Si el índice no contiene un registro índice 
con el valor de la clave de búsqueda del regis¬ 
tro borrado, no hay que hacer nada. 

2. En caso contrario se emprenden las siguien¬ 
tes acciones: 

a. Si el registro borrado era el único regis¬ 
tro con la clave de búsqueda, el sistema 
reemplaza el registro índice correspon¬ 
diente con un registro índice para el 
siguiente valor de la clave de búsqueda 
(en el orden de la clave de búsqueda). Si 
el siguiente valor de la clave de búsque¬ 
da ya tiene una entrada en el índice, se 
borra en lugar de reemplazarla. 

b. En caso contrario, si el registro índice 
para el valor de la clave de búsqueda 
apunta al registro a borrar, el sistema 
actualiza el registro índice para que apun¬ 
te al siguiente registro con el mismo valor 
de la clave de búsqueda. 

Los algoritmos de inserción y borrado para los índi¬ 
ces multinivel se extienden de manera sencilla a partir 
del esquema descrito anteriormente. Al borrar o al inser¬ 
tar se actualiza el índice de nivel más bajo como se des¬ 
cribió anteriormente. Por lo que respecta al índice del 
segundo nivel, el índice de nivel más bajo es simple¬ 
mente un archivo de registros; así, si hay algún cambio 
en el índice de nivel más bajo, se tendrá que actualizar 


el índice del segundo nivel como ya se describió. La 
misma técnica se aplica al resto de niveles del índice, 
si los hubiera. 

12.2.2. índices secundarios 

Los índices secundarios deben ser densos, con una entra¬ 
da en el índice por cada valor de la clave de búsqueda, 
y un puntero a cada registro del archivo. Un índice pri¬ 
mario puede ser disperso, almacenando sólo algunos de 
los valores de la clave de búsqueda, ya que siempre es 
posible encontrar registros con valores de la clave de 
búsqueda intermedios mediante un acceso secuencial a 
parte del archivo, como se describió antes. Si un índi¬ 
ce secundario almacena sólo algunos de los valores de 
la clave de búsqueda, los registros con los valores de la 
clave de búsqueda intermedios pueden estar en cual¬ 
quier lugar del archivo y, en general, no se pueden 
encontrar sin explorar el archivo completo. 

Un índice secundario sobre una clave candidata es 
como un índice denso primario, excepto en que los 
registros apuntados por los sucesivos valores del índi¬ 
ce no están almacenados secuencialmente. Por lo gene¬ 
ral, los índices secundarios están estructurados de mane¬ 
ra diferente a como lo están los índices primarios. Si 
la clave de búsqueda de un índice primario no es una 
clave candidata, es suficiente si el valor de cada entra¬ 
da en el índice apunta al primer registro con ese valor 
en la clave de búsqueda, ya que los otros registros podrí¬ 
an ser alcanzados por una búsqueda secuencial del 
archivo. 

En cambio, si la clave de búsqueda de un índice 
secundario no es una clave candidata, no sería suficiente 
apuntar sólo al primer registro de cada valor de la cla¬ 
ve. El resto de registros con el mismo valor de la cla¬ 
ve de búsqueda podrían estar en cualquier otro sitio del 
archivo, ya que los registros están ordenados según la 
clave de búsqueda del índice primario, en vez de la cla¬ 
ve de búsqueda del índice secundario. Por tanto, un 
índice secundario debe contener punteros a todos los 
registros. 

Se puede usar un nivel adicional de indirección para 
implementar los índices secundarios sobre claves de 
búsqueda que no sean claves candidatas. Los punteros 
en estos índices secundarios no apuntan directamente 
al archivo. En vez de eso, cada puntero apunta a un cajón 
que contiene punteros al archivo. En la Figura 12.5 se 
muestra la estructura del archivo cuenta, con un índice 
secundario que emplea un nivel de indirección adicio¬ 
nal, y teniendo como clave de búsqueda el saldo. 

Siguiendo el orden de un índice primario, una bús¬ 
queda secuencial es eficiente porque los registros del 
archivo están guardados físicamente de la misma mane¬ 
ra a como está ordenado el índice. Sin embargo, no se 
puede (salvo en raros casos excepcionales) almacenar 
el archivo ordenado físicamente por el orden de la cla¬ 
ve de búsqueda del índice primario y la clave de bús¬ 
queda del índice secundario. Ya que el orden de la cla- 
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FIGURA 12.5. índice secundario del archivo cuenta, con la clave no candidata saldo. 


ve secundaria y el orden físico difieren, si se intenta exa¬ 
minar el archivo secuencialmente por el orden de la cla¬ 
ve secundaria, es muy probable que la lectura de cada 
bloque suponga la lectura de un nuevo bloque del dis¬ 
co, lo cual es muy lento. 

El procedimiento ya descrito para borrar e insertar 
se puede aplicar también a los índices secundarios; las 
acciones a emprender son las descritas para los índices 
densos que almacenan un puntero a cada registro del 
archivo. Si un archivo tiene varios índices, siempre que 


se modifique el archivo, se debe actualizar cada uno de 
ellos. 

Los índices secundarios mejoran el rendimiento de 
las consultas que emplean claves que no son la de bús¬ 
queda del índice primario. Sin embargo, implican un 
tiempo adicional importante al modificar la base de 
datos. El diseñador de la base de datos debe decidir qué 
índices secundarios son deseables, según una estima¬ 
ción sobre las frecuencias de las consultas y las modi¬ 
ficaciones. 


12.3. ARCHIVOS DE ÍNDICES DE ÁRBOL B + 


El inconveniente principal de la organización de un 
archivo secuencial indexado reside en que el rendi¬ 
miento, tanto para buscar en el índice como para bus¬ 
car secuencialmente a través de los datos, se degrada 
según crece el archivo. Aunque esta degradación se pue¬ 
de remediar reorganizando el archivo, el rendimiento 
de tales reorganizaciones no es deseable. 

La estructura de índice de árbol B + es la más exten¬ 
dida de las estructuras de índices que mantienen su efi¬ 
ciencia a pesar de la inserción y borrado de datos. Un 
índice de árbol B + toma la forma de un árbol equili¬ 
brado donde los caminos de la raíz a cada hoja del árbol 
son de la misma longitud. Cada nodo que no es una hoja 
tiene entre \n!T] y n hijos, donde n es fijo para cada 
árbol en particular. 

Se verá que la estructura de árbol B + implica una 
degradación del rendimiento al insertar y al borrar, ade¬ 
más de un espacio extra. Este tiempo adicional es acep¬ 


table incluso en archivos con altas frecuencias de modi¬ 
ficación, ya que se evita el coste de reorganizar el archi¬ 
vo. Además, puesto que los nodos podrían estar a lo sumo 
medio llenos (si tienen el mínimo número de hijos) hay 
algo de espacio desperdiciado. Este gasto de espacio adi¬ 
cional también es aceptable dados los beneficios en el 
rendimiento aportados por las estructura de árbol B + . 

12.3.1. Estructura de árbol B + 

Un índice de árbol B + es un índice multinivel pero con 
una estructura que difiere del índice multinivel de un 
archivo secuencial. En la Figura 12.6 se muestra un nodo 
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FIGURA 12.6. Nodo típico de un árbol B + . 
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típico de un árbol B + . Puede contener hasta n - I claves 
de búsqueda K¡, K 2 ,K n , y n punteros P u P 2 ,P n . 
Los valores de la clave de búsqueda de un nodo se man¬ 
tienen ordenados; así, si i < j, entonces K¡ < K f 

Consideraremos primero la estructura de los nodos 

hoja. Para i = 1, 2. n — 1, el puntero P¡ apunta, o bien 

a un registro del archivo con valor de la clave de bús¬ 
queda K¡, o bien a un cajón de punteros, cada uno de los 
cuales apunta a un registro del archivo con valor de la 
clave de búsqueda K¡. La estructura cajón se usa sola¬ 
mente si la clave de búsqueda no forma una clave pri¬ 
maria y si el archivo no está ordenado según la clave de 
búsqueda. El puntero P n tiene un propósito especial que 
discutiremos más adelante. 

En la Figura 12.7 se muestra un nodo hoja en el árbol 
B + del archivo cuenta, donde n vale tres y la clave de 
búsqueda es nombre-sucursal. Obsérvese que, como el 
archivo cuenta está ordenado por nombre-sucursal , los 
punteros en el nodo hoja apuntan directamente al ar¬ 
chivo. 

Ahora que se ha visto la estructura de un nodo hoja, 
se mostrará cómo los valores de la clave de búsqueda se 
asignan a nodos concretos. Cada hoja puede guardar has¬ 
ta n - 1 valores. Está permitido que los nodos hojas con¬ 
tengan al menos f (n - l)/2] valores. Los rangos de los 
valores en cada hoja no se solapan. Así, si L¡ y L¡ son 
nodos hoja e i < j, entonces cada valor de la clave de bús¬ 
queda en L¡ es menor que cada valor de la clave en L -. Si 
el índice de árbol B + es un índice denso, cada valor de la 
clave de búsqueda debe aparecer en algún nodo hoja. 

Ahora se puede explicar el uso del puntero P n . Dado 
que existe un orden lineal en las hojas basado en los 
valores de la clave de búsqueda que contienen, se usa 
P n para encadenar juntos los nodos hojas en el orden de 
la clave de búsqueda. Esta ordenación permite un pro¬ 
cesamiento secuencial eficaz del archivo. 

Los nodos intemos del árbol B + forman un índice mul- 
tinivel (disperso) sobre los nodos hoja. La estructura de 
los nodos internos es la misma que la de los nodos hoja 
excepto que todos los punteros son punteros a nodos del 
árbol. Un nodo intemo podría guardar hasta n punteros 
y debe guardar al menos fn/2] punteros. El número de 


punteros de un nodo se llama grado de salida del nodo. 

Consideremos un nodo que contiene m punteros. Para 
i = 2, 3,..., m— 1, el puntero P¡ apunta al subárbol que 
contiene los valores de la clave de búsqueda menores 
que K¡ y mayor o igual que K i A . El puntero P m apunta 
a la parte del subárbol que contiene los valores de la cla¬ 
ve mayores o iguales que K m] , y el puntero P { apunta 
a la parte del subárbol que contiene los valores de la cla¬ 
ve menores que K { . 

A diferencia de otros nodos internos, el nodo raíz 
puede tener menos de fn/2j ; sin embargo, debe tener 
al menos dos punteros, a menos que el árbol consista en 
un solo nodo. Siempre es posible construir un árbol B + , 
para cualquier n, que satisfaga los requisitos anteriores. 
En la Figura 12.8 se muestra un árbol B + completo para 
el archivo cuenta (n = 3). Por simplicidad se omiten los 
punteros al propio archivo y los punteros nulos. Como 
un ejemplo de un árbol B + en el cual la raíz debe tener 
menos de \nl2~] valores, en la Figura 12.9 se muestra 
un árbol B + para el archivo cuenta con n = 5. 

En todos los ejemplos mostrados de árboles B + , éstos 
están equilibrados. Es decir, la longitud de cada cami¬ 
no desde la raíz a cada nodo hoja es la misma. Esta pro¬ 
piedad es un requisito de los árboles B + . De hecho, la 
«B» en árbol B + proviene del inglés balanced (equili¬ 
brado). Es esta propiedad de equilibrio de los árboles 
B + la que asegura un buen rendimiento para las bús¬ 
quedas, inserciones y borrados. 

12.3.2. Consultas con árboles B* 

Considérese ahora cómo procesar consultas usando árbo¬ 
les B + . Supóngase que se desean encontrar todos los 
registros cuyo valor de la clave de búsqueda sea V. La 
Figura 12.10 muestra el pseudocódigo para hacerlo. Pri¬ 
mero se examina el nodo raíz para buscar el menor valor 
de la clave de búsqueda mayor que V. Supóngase que 
este valor de la clave de búsqueda es K¡. Siguiendo el 
puntero P¡ hasta otro nodo. Si no se encuentra ese valor, 
entonces k>=K m ~ l , donde m es el número de punteros 
del nodo. Es este caso se sigue P m hasta otro nodo. En 
el nodo alcanzado anteriormente se busca de nuevo el 
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FIGURA 12.7. Nodo hoja para el índice del árbol B + de cuenta (n = 3). 
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FIGURA 12.8. Árbol B + para el archivo cuenta (n = 3). 



FIGURA 12.9. Árbol B + para el archivo cuenta (n = 5). 


menor valor de la clave de búsqueda que es mayor que 
V para seguir el puntero correspondiente. Finalmente se 
alcanza un nodo hoja. En este nodo hoja, si se encuen¬ 
tra que el valor K¡ es igual a V, entonces el puntero P¡ 
nos ha conducido al registro o cajón deseado. Si no se 
encuentra el valor V en el nodo hoja, no existe ningún 
registro con el valor clave V. 

De esta manera, para procesar una consulta, se tie¬ 
ne que recorrer un camino en el árbol desde la raíz has¬ 
ta algún nodo hoja. Si hay K valores de la clave de bús¬ 
queda en el archivo, este camino no será más largo que 
flog m /21 (*)1 • 


procedure buscar )valor V) 
set C = nodo raíz 

while C no sea un nodo raíz begin 

Sea K¡ = menor valor de la clave de búsqueda, si lo hay, mayor que V 
¡f no hay tal valor then begin 

Sea m = el número de punteros en el nodo 
Sea C = nodo apuntado por P m 

end 

else Sea C = el nodo apuntado por P, 

end 

¡f hay un valor de clave /C, en Ctal que K¡= C 

then el puntero P, conduce al registro o cajón deseado 
else no existe ningún registro con el valor clave k 

end procedure 

FIGURA 12.10. Consulta con un árbol B + . 


En la práctica sólo se accede a unos cuantos nodos. 
Generalmente un nodo se construye para tener el mis¬ 
mo tamaño que un bloque de disco, el cual ocupa nor¬ 
malmente 4 KB. Con una clave de búsqueda del tama¬ 
ño de 12 bytes y un tamaño del puntero a disco de 
8 bytes, n está alrededor de 200. Incluso con una esti¬ 
mación más conservadora de 32 bytes para el tama¬ 
ño de la clave de búsqueda, n está en torno a 100. Con 
n = 100, si se tienen un millón de valores de la clave de 
búsqueda en el archivo, una búsqueda necesita sola¬ 
mente [log so (1.000.000)] = 4 accesos a nodos. Por 
tanto, se necesitan leer a lo sumo cuatro bloques del dis- 
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co para realizar la búsqueda. Normalmente, el nodo raíz 
del árbol es el más accedido y por ello se guarda en una 
memoria intermedia; así solamente se necesitan tres o 
menos lecturas del disco. 

Una diferencia importante entre las estructuras de 
árbol B + y los árboles en memoria, tales como los árbo¬ 
les binarios, está en el tamaño de un nodo y, por tanto, 
la altura del árbol. En un árbol binario, cada nodo es 
pequeño y tiene a lo sumo dos punteros. En un árbol B + , 
cada nodo es grande —normalmente un bloque del dis¬ 
co— y un nodo puede tener un gran número de punte¬ 
ros. Así, los árboles B + tienden a ser bajos y anchos, en 
lugar de los altos y estrechos árboles binarios. En un 
árbol equilibrado, el camino de una búsqueda puede tener 
una longitud de riog 2 (K) j , donde K es el número de 
valores de la clave de búsqueda. Con K = 1.000.000, 
como en el ejemplo anterior, un árbol binario equilibra¬ 
do necesita alrededor de 20 accesos a nodos. Si cada 
nodo estuviera en un bloque del disco distinto, serían 
necesarias 20 lecturas a bloques para procesar la bús¬ 
queda, en contraste con las cuatro lecturas del árbol B + . 

12.3.3. Actualizaciones en árboles B + 

El borrado y la inserción son más complicados que 
las búsquedas, ya que podría ser necesario dividir un 
nodo que resultara demasiado grande como resultado 
de una inserción, o fusionar nodos si un nodo se vol¬ 
viera demasiado pequeño (menor que [ni 2j punte¬ 
ros). Además, cuando se divide un nodo o se fusionan 
un par de ellos, se debe asegurar que el equilibrio del 
árbol se mantiene. Para presentar la idea que hay 
detrás del borrado y la inserción en un árbol B + , asu¬ 
miremos que los nodos nunca serán demasiado gran¬ 
des ni demasiado pequeños. Bajo esta suposición, el 
borrado y la inserción se realizan como se indica a 
continuación. 

• Inserción. Usando la misma técnica que para bus¬ 
car, se busca un nodo hoja donde tendría que apa¬ 
recer el valor de la clave de búsqueda. Si el valor 
de la clave de búsqueda ya aparece en el nodo hoja, 
se inserta un nuevo registro en el archivo y, si es 
necesario, un puntero al cajón. Si el valor de la cla¬ 
ve de búsqueda no aparece, se inserta el valor en el 
nodo hoja de tal manera que las claves de búsque¬ 
da permanezcan ordenadas. Luego insertamos el 
nuevo registro en el archivo y, si es necesario, cre¬ 
amos un nuevo cajón con el puntero apropiado. 


• Borrado. Usando la misma técnica que para bus¬ 
car, se busca el registro a borrar y se elimina del 
archivo. Si no hay un cajón asociado con el valor 
de la clave de búsqueda o si el cajón se queda vacío 
como resultado del borrado, se borra el valor de la 
clave de búsqueda del nodo hoja. 

Pasamos ahora a considerar un ejemplo en el que se 
tiene que dividir un nodo. Por ejemplo, queremos inser¬ 
tar un registro en el árbol B + de la Figura 12.8, cuyo 
valor de nombre-sucursal es «Cádiz». Usando el algo¬ 
ritmo de búsqueda, «Cádiz» debería aparecer en el nodo 
que incluye «Barcelona» y «Daimiel». No hay sitio para 
insertar el valor de la clave de búsqueda «Cádiz». Por 
tanto, se divide el nodo en otros dos nodos. En la Figu¬ 
ra 12.11 se muestran los nodos hoja que resultan de 
insertar «Cádiz» y de dividir el nodo que incluía «Bar¬ 
celona» y «Daimiel». En general, si tenemos n valores 
de la clave de búsqueda (los n— 1 valores del nodo hoja 
más el valor a insertar), pondremos fn/2~| en el nodo 
existente y el resto de valores en el nuevo nodo. 

Para dividir un nodo hoja hay que insertar un nuevo 
nodo hoja en el árbol B + . En el ejemplo, el nuevo nodo 
tiene a «Daimiel» como el valor más pequeño de la cla¬ 
ve de búsqueda. Luego hay que insertar este valor de la 
clave de búsqueda en el padre del nodo hoja dividido. 
En el árbol B + de la Figura 12.12 se muestra el resulta¬ 
do de la inserción. El valor «Daimiel» de la clave de 
búsqueda se ha insertado en el padre. Ha sido posible 
llevar a cabo esta inserción porque había sitio para aña¬ 
dir un valor de la clave de búsqueda. Si no hubiera sitio, 
se tendría que dividir el padre. En el peor de los casos, 
todos los nodos en el camino hacia la raíz se tendrían 
que dividir. Si la propia raíz se tuviera que dividir, el 
árbol sería más profundo. 

La técnica general para la inserción en un árbol B + 
es determinar el nodo hoja h en el cual realizar la inser¬ 
ción. Si es necesario dividir, se inserta el nuevo nodo 
dentro del padre del nodo h. Si esta inserción produce 
otra división, procederíamos recursivamente o bien has¬ 
ta que una inserción no produzca otra división o bien 
hasta crear una nueva raíz. 

En la Figura 12.13 se bosqueja el algoritmo de inser¬ 
ción en pseudocódigo. En el pseudocódigo L.K¡ y L.P¡ 
denotan al í-ésimo valor y el í-ésimo puntero en el nodo 
L, respectivamente. El pseudocódigo también hace uso 
de la función padre(L ) para encontrar el padre del nodo 
L. Se puede obtener una lista de los nodos en el cami¬ 
no de la raíz a la hoja mientras buscamos el nodo hoja 



FIGURA 12.11. División del nodo hoja tras la inserción de «Cádiz». 
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FIGURA 12.12. Inserción de «Cádiz» en el árbol B + de la Figura 12.8. 


para usarlos después a la hora de encontrar eficazmen¬ 
te el padre de cualquier nodo del camino. El pseudocó- 
digo hace referencia a insertar una entrada (V, P) en un 
nodo. En el caso de nodos hoja, realmente el puntero a 


una entrada precede al valor de la clave, de tal manera 
que efectivamente se almacena P en el nodo hoja pre¬ 
cediendo a V. Para los nodos internos, se almacena P 
justo después de V. 


procedure insertar [valor V, puntero P) 

encontrar el nodo hoja L que debe contener el valor V 
insertar_entrada(Z., V, P) 

end procedure 

procedure ¡nsertar_entrada [nodo L, valor V, puntero P) 

¡f (L tiene espacio para [V, P)) 
then insertar ( V, P) en L 
else begin /* Dividir L */ 

Crear el nodo L' 

Sea V el valor en /(,, ...,/Cn-i tal que exactamente f ni 21 de los valores L.K U 1/son menores que V 

Sea m el menor valor tal que L.K m > V 
/* Nota: V tiene que ser L.K m o V*/ 

¡f [L es una hoja) then begin 

mover LP m , L.K m , L.PL.K„_ , a L 
ii[V< V) then insertar ( V, P) en L 
else insertar (K ñ en L 

end 

else begin 

¡f ( V = V') /* V es el menor valor que irá en L' */ 
then añadir P, L.K m , .... L.P^ V L.KL.P n a L 
else añadir L.P m , ..., L.PL.K^i, L.P n a L' 
borrar L.K m , ..., L.PL.KL.P n de L 
if[V< V') then insertar [V, P) en L 
else if [V< V') then insertar [V, P) en i 
/* El caso V = V ya se trató anteriormente */ 

end 

if [L no es la raíz del árbol) 

then ¡nsertar_entrada(padre(Z.), V, L'); 

else begin 

crear un nuevo nodo R con hijos los nodos L y L 1 y con el único valor V 
hacer de R la raíz del árbol 

end 

if (/_) es un nodo hoja then begin /* Fijar los siguientes punteros a los hijos */ 
hacer L'.P n = L.P n ; 
hacer L.P n = L' 

end 

end 

end procedure 

FIGURA 12.13. Inserción de una entrada en un árbol B + . 
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A continuación se consideran los borrados que pro¬ 
vocan que el árbol se quede con muy pocos punteros. 
Primero se borra «Daimiel» del árbol B + de la Figura 
12.12. Para ello se localiza la entrada «Daimiel» usan¬ 
do el algoritmo de búsqueda. Cuando se borra la entra¬ 
da «Daimiel» de su nodo hoja, la hoja se queda vacía. 
Ya que en el ejemplo n = 3 y 0 < \{n - l)/2j , este nodo 
se debe borrar del árbol B + . Para borrar un nodo hoja se 
tiene que borrar el puntero que le llega desde su padre. 
En el ejemplo, este borrado deja al nodo padre, el cual 
contenía tres punteros, con sólo dos punteros. Ya que 
2 >= fra/2j , el nodo es todavía lo suficientemente gran¬ 
de y la operación de borrado se completa. El árbol B + 
resultante se muestra en la Figura 12.14. 

Cuando un borrado se hace sobre el padre de un nodo 
hoja, el propio nodo padre podría quedar demasiado 
pequeño. Esto es exactamente los que ocurre si se borra 
«Pamplona» del árbol B + de la Figura 12.14. El borra¬ 
do de la entrada Pamplona provoca que un nodo hoja 
se quede vacío. Cuando se borra el puntero a este nodo 
en su padre, el padre sólo se queda con un puntero. Así, 
n = 3, \n!T\ = 2 y queda tan sólo un puntero, que es 
demasiado poco. Sin embargo, ya que el nodo padre 
contiene información útil, no podemos simplemente 
borrarlo. En vez de eso, se busca el nodo hermano (el 
nodo interno que contiene al menos una clave de bús¬ 
queda, Madrid). Este nodo hermano tiene sitio para colo¬ 


car la información contenida en el nodo que quedó 
demasiado pequeño, así que se fusionan estos nodos, de 
tal manera que el nodo hermano ahora contiene las cla¬ 
ves «Madrid» y «Reus». El otro nodo (el nodo que con¬ 
tenía solamente la clave de búsqueda «Reus») ahora 
contiene información redundante y se puede borrar des¬ 
de su padre (el cual resulta ser la raíz del ejemplo). En 
la Figura 12.15 se muestra el resultado. Hay que obser¬ 
var que la raíz tiene solamente un puntero hijo como 
resultado del borrado, así que éste se borra y el hijo soli¬ 
tario se convierte en la nueva raíz. De esta manera la 
profundidad del árbol ha disminuido en una unidad. 

No siempre es posible fusionar nodos. Como ejem¬ 
plo se borrará «Pamplona» del árbol B + de la Figura 
11.11. En este ejemplo, la entrada «Daimiel» es toda¬ 
vía parte del árbol. Una vez más, el nodo hoja que con¬ 
tiene «Pamplona» se queda vacío. El padre del nodo 
hoja se queda también demasiado pequeño (únicamen¬ 
te con un puntero). De cualquier modo, en este ejem¬ 
plo, el nodo hermano contiene ya el máximo número de 
punteros: tres. Así, no puede acomodar a un puntero 
adicional. La solución en este caso es redistribuir los 
punteros de tal manera que cada hermano tenga dos pun¬ 
teros. El resultado se muestra en la Figura 12.16. Obsér¬ 
vese que la redistribución de los valores necesita de un 
cambio en el valor de la clave de búsqueda en el padre 
de los dos hermanos. 



FIGURA 12.14. Borrado de «Daimiel» del árbol B + de la Figura 12.12. 



FIGURA 12.15. Borrado de «Pamplona» del árbol B + de la Figura 12.14. 
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FIGURA 12.16. Borrado de «Pamplona» del árbol B + de la Figura 12.12. 


En general, para borrar un valor en un árbol B + se 
realiza una búsqueda según el valor y se borra. Si el 
nodo es demasiado pequeño, se borra desde su padre. 
Este borrado se realiza como una aplicación recursiva 
del algoritmo de borrado hasta que se alcanza la raíz, 
un nodo padre queda lleno de manera adecuada después 
de borrar, o hasta aplicar una redistribución. 

En la Figura 12.17 se describe el pseudocódigo para 
el borrado en un árbol B + . El procedimiento inter- 
cambiar_variables(L, L') simplemente cambia de lugar 
los valores (punteros) de las variables L y L'; este cam¬ 
bio no afecta al árbol en sí mismo. El pseudocódigo 
utiliza la condición «muy pocos valores/punteros». 
Para nodos internos, este criterio quiere decir menos 
que r«/21 punteros; para nodos hoja, quiere decir 
menos que f(n-l)/2j valores. El pseudocódigo rea¬ 
liza la redistribución tomando prestada una sola entra¬ 
da desde un nodo adyacente. También se puede redis¬ 
tribuir mediante la distribución equitativa de entradas 
entre dos nodos. El pseudocódigo hace referencia al 
borrado de una entrada {V, P) desde un nodo. En el 
caso de los nodos hoja, el puntero a una entrada real¬ 
mente precede al valor de la clave; así, el puntero P 
precede al valor de la clave V. Para nodos internos, 
P sigue al valor de la clave V. 

Es interesante señalar que como resultado de un 
borrado, un valor de la clave de un nodo interno del 
árbol B + puede que no esté en ninguna hoja del árbol. 

Aunque las operaciones inserción y borrado en árbo¬ 
les B + son complicadas, requieren relativamente pocas 
operaciones, lo que es un beneficio importante dado el 
coste de las operaciones E/S. Se puede demostrar que 
el número de operaciones E/S necesarias para una inser¬ 
ción o borrado es, en el peor de los casos, proporcional 
a log \ nl2 -\ (K), donde n es el número máximo de punte¬ 
ros en un nodo y K es el número de valores de la clave 
de búsqueda. En otras palabras, el coste de las opera¬ 
ciones inserción y borrado es proporcional a la altura 
del árbol B + y es por lo tanto bajo. Debido a la veloci¬ 
dad de las operaciones en los árboles B + , estas estruc¬ 


turas de índice se usan frecuentemente al implementar 
las bases de datos. 

12.3.4. Organización de archivos con árboles B + 

Como se mencionó en el Apartado 12.3, el inconve¬ 
niente de la organización de archivos secuenciales de 
índices es la degradación del rendimiento según crece 
el archivo: con el crecimiento, un porcentaje mayor de 
registros índice y registros reales se desaprovechan y se 
almacenan en bloques de desbordamiento. Se resuelve 
la degradación de las búsquedas en el índice mediante 
el uso de índices de árbol B + en el archivo. También se 
soluciona el problema de la degradación al almacenar 
los registros reales utilizando el nivel de hoja del árbol 
B + para almacenar los registros reales en los bloques. 
En estas estructuras, la estructura del árbol B + se usa no 
sólo como un índice, sino también como un organiza¬ 
dor de los registros dentro del archivo. En la organi¬ 
zación de archivo con árboles B + , los nodos hoja del 
árbol almacenan registros, en lugar de almacenar pun¬ 
teros a registros. En la Figura 12.18 se muestra un ejem¬ 
plo de la organización de un archivo con un árbol B + . 
Ya que los registros son normalmente más grandes que 
los punteros, el número máximo de registros que se pue¬ 
den almacenar en un nodo hoja es menor que el núme¬ 
ro de punteros en un nodo interno. Sin embargo, toda¬ 
vía se requiere que los nodos hoja estén llenos al menos 
hasta la mitad. 

La inserción y borrado de registros en una organi¬ 
zación de archivo con árboles B + se trata del mismo 
modo que la inserción y borrado de entradas en un índi¬ 
ce de árbol B + . Cuando se inserta un registro con un 
valor de clave v, se localiza el bloque que debería con¬ 
tener ese registro mediante la búsqueda en el árbol B + 
de la mayor clave que sea < v. Si el bloque localizado 
tiene bastante espacio libre para el registro, se almace¬ 
na el registro en el bloque. De no ser así, como en una 
inserción en un árbol B + , se divide el bloque en dos y 
se redistribuyen sus registros (en el orden de la clave 
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procedure borrar ( valor V, puntero P) 

encontrar el nodo hoja L que contiene ( V, P) 
borrar_entrada(Z., V, P) 

end procedure 

procedure borrar_entrada (nodo L, valor V, puntero P) 
borrar ( V, P) de L 

¡f (L es la raíz and L tiene sólo un hijo) 
then hacer del hijo de L la nueva raíz del árbol y borrar L 
else ¡f (L tiene muy pocos valores/punteros) then begin 
Sea /_' el anterior o el siguiente hijo de padre(L) 

Sea V el valor enter los punteros L y L' en padre(L) 

¡f las entradas en L y L' caben en un solo nodo) 
then begin /* Fundir nodos */ 

¡f (L es un predecesor de L) then intercamb¡ar_var¡ables(/_, L) 

¡f (L no es una hoja) 

then concatenar V y todos los punteros y valores de L a L' 
else concatenar todos los pares (K¡, P¡) de L a L'; hacer L'.P n = L.P n 

borrar_entrada (padre(L), V, L ); borrar el nodo L 

end 

else begin /* Redistribución : prestar una entrada de /_'*/ 
if (L es un predecesor de L) then begin 
¡f (L es un nodo Interno) then begin 

sea m tal que L'.P m es el último puntero en L 
suprimir ( L'.K m _ 1 , L'.PJ de L 

insertar ( L'.P m , V') como el primer puntero y valor en L, desplazando otros punteros y valores a la derecha 
reemplazar V en padre(L) por L'.K ^ m _ 1 

end 

else begin 

sea m tal que ( L'.P m , L'.KJ es el último par puntero/valor en i 
suprimir (L'.P m , L'.K m ) de L' 

insertar ( L'.P m , L'.K m ) como el primer puntero y valor en L, desplazando otros punteros y valores a la derecha 
reemplazar V en padre(L) por L'.K m 

end 

end 

else ... caso simétrico al then ... 

end 

end 

end procedure 

FIGURA 12.17. Borrado de elementos de un árbol B + . 


del árbol B + ) creando espacio para el nuevo registro. 
Esta división se propaga hacia arriba en el árbol B + de 
la manera usual. Cuando se borra un registro, primero 
se elimina del bloque que lo contiene. Si como resulta¬ 


do un bloque B llega a ocupar menos que la mitad, los 
registros en B se redistribuyen con los registros en un 
bloque B' adyacente. Si se asume que los registros son 
de tamaño ñjo, cada bloque contendrá por lo menos la 



FIGURA 12.18. Organización de archivos con árboles B + . 
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mitad de los registros que pueda contener como máxi¬ 
mo. Los nodos internos del árbol B + se actualizan por 
tanto de la manera habitual. 

Cuando un árbol B + se utiliza para la organización 
de un archivo, la utilización del espacio es particular¬ 
mente importante, ya que el espacio ocupado por los 
registros es mucho mayor que el espacio ocupado por 
las claves y punteros. Se puede mejorar la utilización 
del espacio en un árbol B + implicando a más nodos her¬ 
manos en la redistribución durante las divisiones y fusio¬ 
nes. La técnica es aplicable a los nodos hoja y nodos 
internos y funciona como sigue. 

Durante la inserción, si un nodo está lleno se inten¬ 
ta redistribuir algunas de sus entradas en uno de los 
nodos adyacentes para hacer sitio a una nueva entra¬ 
da. Si este intento falla porque los nodos adyacentes 
están llenos, se divide el nodo y las entradas entre uno 
de los nodos adyacentes y los dos nodos que se obtie¬ 
nen al dividir el nodo original. Puesto que los tres 
nodos juntos contienen un registro más que puede enca¬ 
jar en dos nodos, cada nodo estará lleno aproximada¬ 
mente hasta sus dos terceras partes. Para ser más pre¬ 


cisos, cada nodo tendrá por lo menos \_2n/3\ entra¬ 
das, donde n es el número máximo de entradas que 
puede tener un nodo (\_n\ denota el mayor entero 
menor o igual que x; es decir, eliminamos la parte frac¬ 
cionaria si la hay). 

Durante el borrado de un registro, si la ocupación de 
un nodo está por debajo de |_2ft/3J , se intentará tomar 
prestada una entrada desde uno de sus nodos hermanos. 
Si ambos nodos hermanos tienen |_2n/3J registros, en 
lugar de tomar prestada una entrada, se redistribuyen 
las entradas en el nodo y en los dos nodos hermanos 
uniformemente entre dos de los nodos y se borra el ter¬ 
cer nodo. Se puede usar este enfoque porque el núme¬ 
ro total de entradas es 3 |_2n/3J - 1, lo cual es menor 
que 2 n. Utilizando tres nodos adyacentes para la redis¬ 
tribución se garantiza que cada nodo pueda tener |_3n/4 ¡ 
entradas. En general, si hay m nodos (m - 1 hermanos) 
implicados en la redistribución se garantiza que cada 
nodo pueda contener al menos |_(m - 1 )n/m entradas. 
Sin embargo, el costo de la actualización se vuelve 
mayor según haya más nodos hermanos involucrados 
en la redistribución. 


12.4. ARCHIVOS CON ÍNDICES DE ÁRBOL B 


Los índices de árbol B son similares a los índices de 
árbol B + . La diferencia principal entre los dos enfoques 
es que un árbol B elimina el almacenamiento redun¬ 
dante de los valores de la clave búsqueda. En el árbol 
B + de la Figura 12.12, las claves de búsqueda «Daimiel», 
«Madrid», «Reus» y «Pamplona» aparecen dos veces. 
Cada valor de clave de búsqueda aparece en algún nodo 
hoja; algunos se repiten en nodos internos. 

Un árbol B permite que los valores de la clave de 
búsqueda aparezcan solamente una vez. En la Figura 
12.19 se muestra un árbol B que representa las mismas 


claves de búsqueda que el árbol B + de la Figura 12.12. 
Ya que las claves de búsqueda no están repetidas en el 
árbol B, sería posible almacenar el índice empleando 
menos nodos del árbol que con el correspondiente índi¬ 
ce de árbol B + . Sin embargo, puesto que las claves de 
búsqueda que aparecen en los nodos internos no apare¬ 
cen en ninguna otra parte del árbol B, nos vemos obli¬ 
gados a incluir un campo adicional para un puntero por 
cada clave de búsqueda de un nodo interno. Estos pun¬ 
teros adicionales apuntan a registros del archivo o a los 
cajones de la clave de búsqueda asociada. 



Cajón Cajón Cajón Cajón Cajón 

de Barcelona de Cádiz de Madrid de Pamplona de Ronda 


FIGURA 12.19. Árbol B equivalente al árbol B + de la Figura 12.12. 
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Un nodo hoja generalizado de un árbol B aparece en 
la Figura 12.20a; un nodo interno aparece en la Figura 
12.20b. Los nodos hoja son como en los árboles B + . En 
los nodos internos los punteros P¡ son los punteros del 
árbol que se utilizan también para los árboles B + , mien¬ 
tras que los punteros B¡ en los nodos internos son pun¬ 
teros a cajones o registros del archivo. En la figura del 
árbol B generalizado hay n— 1 claves en el nodo hoja, 
mientras que hay m - 1 claves en el nodo intemo. Esta 
discrepancia ocurre porque los nodos internos deben 
incluir los punteros B¡, y de esta manera se reduce el 
número de claves de búsqueda que pueden contener 
estos nodos. Claramente, m < n, pero la relación exac¬ 
ta entre m y n depende del tamaño relativo de las cla¬ 
ves de búsqueda y de los punteros. 

El número de nodos accedidos en una búsqueda en 
un árbol B depende de dónde esté situada la clave de 
búsqueda. Una búsqueda en un árbol B + requiere atra¬ 
vesar un camino desde la raíz del árbol hasta algún 
nodo hoja. En cambio, algunas veces es posible encon¬ 
trar en un árbol B el valor deseado antes de alcanzar 
el nodo hoja. Sin embargo, hay que realizar aproxi¬ 
madamente n accesos según cuántas claves haya alma¬ 
cenadas tanto en el nivel de hoja de un árbol B como 
en los niveles internos de hoja y, dado que n es nor¬ 
malmente grande, la probabilidad de encontrar ciertos 
valores pronto es relativamente pequeña. Por otra par¬ 
te, el hecho de que menos claves de búsqueda aparez¬ 
can en los nodos internos del árbol B, comparado con 


los árboles B + , implica que un árbol B tiene un grado 
de salida menor y, por lo tanto, puede que tenga una 
profundidad mayor que el correspondiente al árbol B + . 
Así, la búsqueda en un árbol B es más rápida para algu¬ 
nas claves de búsqueda pero más lenta para otras, aun¬ 
que en general, el tiempo de la búsqueda es todavía 
proporcional al logaritmo del número de claves de bús¬ 
queda. 

El borrado en un árbol B es más complicado. En un 
árbol B + la entrada borrada siempre aparece en una hoja. 
En un árbol B, la entrada borrada podría aparecer en un 
nodo intemo. El valor apropiado a colocar en su lugar 
se debe elegir del subárbol del nodo que contiene la 
entrada borrada. Concretamente, si se borra la clave de 
búsqueda K¡, la clave de búsqueda más pequeña que 
aparezca en el subárbol del puntero P¡ + 1 se debe tras¬ 
ladar al campo ocupado anteriormente por K¡. Será nece¬ 
sario tomar otras medidas si ahora el nodo hoja tuviera 
pocas entradas. Por el contrario, la inserción en un árbol 
B es sólo un poco más complicada que la inserción en 
un árbol B + . 

Las ventajas de espacio que tienen los árboles B son 
escasas para índices grandes y normalmente no son de 
mayor importancia los inconvenientes que hemos adver¬ 
tido. De esta manera, muchos implementadores de sis¬ 
temas de bases de datos aprovechan la sencillez estruc¬ 
tural de un árbol B + . Los detalles de los algoritmos de 
inserción y borrado para árboles B se estudian en los 
ejercicios. 


12.5. ASOCIACIÓN ESTÁTICA 


Un inconveniente de la organización de archivos secuen- 
ciales es que hay que acceder a una estructura de índi¬ 
ces para localizar los datos o utilizar una búsqueda bina¬ 
ria y, como resultado, más operaciones de E/S. La 
organización de archivos basada en la técnica de aso¬ 
ciación ( liashing) permite evitar el acceso a la estruc¬ 
tura de índice. La asociación también proporciona una 
forma de construir índices. Se estudiarán las organiza¬ 
ciones de archivos e índices basados en asociación en 
los próximos apartados. 


12.5.1. Organización de archivos 
por asociación 

En una organización de archivos por asociación se 

obtiene la dirección del bloque de disco que contiene el 
registro deseado mediante el cálculo directo de una fun¬ 
ción sobre el valor de la clave búsqueda del registro. En 
nuestra descripción de asociación, utilizaremos el tér¬ 
mino cajón ( bucket ) para indicar una unidad de alma¬ 
cenamiento que puede guardar uno o más registros. Un 
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FIGURA 12.20. Nodos típicos de un árbol B. (a) Nodo hoja, (b) Nodo interno. 
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cajón es normalmente un bloque de disco, aunque tam¬ 
bién se podría elegir más pequeño o más grande que un 
bloque de disco. 

Formalmente, sea K el conjunto de todos los valo¬ 
res de clave de búsqueda y sea B el conjunto de todas 
las direcciones de cajón. Una fundón de asociación 
h es una función de K a B. Sea h una función asocia¬ 
ción. 

Para insertar un registro con clave de búsqueda K¡, 
calcularemos h(K¡), lo que proporciona la dirección del 
cajón para ese registro. Se supone que por ahora hay 
espacio en el cajón para almacenar el registro. Enton¬ 
ces, el registro se almacena en este cajón. 

Para realizar una búsqueda con el valor K¡ de la cla¬ 
ve de búsqueda, simplemente se calcula h(K¡) y luego 
se busca el cajón con esa dirección. Supongamos que 
dos claves de búsqueda, K 5 y K 1 , tienen el mismo valor 
de asociación; esto es, h(K 5 ) = h(K 7 ). Si se realiza una 
búsqueda en K 5 , el cajón h(K 5 ) contendrá registros con 
valores de la clave de búsqueda K 5 y registros con valo¬ 
res de la clave de búsqueda K 7 . Así, hay que compro¬ 
bar el valor de clave de búsqueda de cada registro en 
el cajón para verificar que el registro es el que quere¬ 
mos. 

El borrado es igual de sencillo. Si el valor de clave 
de búsqueda del registro a borrar es K¡, se calcula h(Kf 
después se busca el correspondiente cajón para ese regis¬ 
tro y se borra el registro del cajón. 

12.5.1.1. Funciones de asociación 

La peor función posible de asociación asigna todos los 
valores de la clave de búsqueda al mismo cajón. Tal fun¬ 
ción no es deseable, ya que todos los registros tienen 
que guardarse en el mismo cajón. Una búsqueda tiene 
que examinar cada registro hasta encontrar el deseado. 
Una función de asociación ideal distribuye las claves 
almacenadas uniformemente a través de los cajones para 
que cada uno de ellos tenga el mismo número de regis¬ 
tros. 

Puesto que no se sabe durante la etapa de diseño qué 
valores de la clave de búsqueda se almacenarán en el 
archivo, se pretende elegir una función de asociación 
que asigne los valores de las claves de búsqueda a los 
cajones de manera que se cumpla lo siguiente: 

• Distribución uniforme. Esto es, cada cajón tiene 
asignado el mismo número de valores de la clave 
de búsqueda dentro del conjunto de todos los va¬ 
lores posibles de la clave de búsqueda. 

• Distribución aleatoria. Esto es, en el caso prome¬ 
dio, cada cajón tendrá casi el mismo número de 
valores asignados a él, sin tener en cuenta la dis¬ 
tribución actual de los valores de la clave de bús¬ 
queda. Para ser más exactos, el valor de asociación 
no será correlativo a ninguna orden exterior visi¬ 
ble en los valores de la clave de búsqueda, como 
por ejemplo el orden alfabético o el orden deter¬ 
minado por la longitud de las claves de búsqueda; 


la función de asociación tendrá que parecer ser ale¬ 
atoria. 

Como una ilustración de estos principios, vamos a esco¬ 
ger una función de asociación para el archivo cuenta uti¬ 
lizando la clave búsqueda nombre-sucursal. La función 
de asociación que se escoja debe tener las propiedades 
deseadas no sólo en el ejemplo del archivo cuenta que se 
ha estado utilizando, sino también en el archivo cuenta de 
tamaño real para un gran banco con muchas sucursales. 

Supóngase que se decide tener 26 cajones y se defi¬ 
ne una función de asociación que asigna a los nombres 
que empiezan con la letra í-ésima del alfabeto el i-ési- 
mo cajón. Esta función de asociación tiene la virtud de 
la simplicidad, pero no logra proporcionar una distri¬ 
bución uniforme, ya que se espera tener más nombres 
de sucursales que comienzan con letras como «B» y 
«R» que con «Q» y «X», por citar un ejemplo. 

Ahora supóngase que se quiere una función de aso¬ 
ciación en la clave de búsqueda saldo. Supóngase que 
el saldo mínimo es 1 y el saldo máximo es 100.000, se 
utiliza una función de asociación que divide el valor en 
10 rangos, 1-10.000, 10.001-20.000, y así sucesiva¬ 
mente. La distribución de los valores de la clave de bús¬ 
queda es uniforme (ya que cada cajón tiene el mismo 
número de valores del saldo diferente), pero no es alea¬ 
torio. Los registros con saldos entre 1 y 10.000 son más 
comunes que los registros con saldos entre 90.001 y 
100.000. Como resultado, la distribución de los regis¬ 
tros no es uniforme: algunos cajones reciben más regis¬ 
tros que otros. Si la función tiene una distribución alea¬ 
toria, incluso si hubiera estas correlaciones en las claves 
de búsqueda, la aleatoriedad de la distribución hará que 
todos los cajones tengan más o menos el mismo núme¬ 
ro de registros, siempre que cada clave de búsqueda apa¬ 
rezca sólo en una pequeña fracción de registros. (Si una 
única clave de búsqueda aparece en una gran fracción 
de registros, el cajón que la contiene probablemente ten¬ 
ga más registros que otros cajones, independientemen¬ 
te de la función de asociación usada.) 

Las funciones de asociación típicas realizan cálcu¬ 
los sobre la representación binaria interna de la máqui¬ 
na para los caracteres de la clave de búsqueda. Una fun¬ 
ción de asociación simple de este tipo, en primer lugar, 
calcula la suma de las representaciones binarias de los 
caracteres de una clave y, posteriormente, devuelve la 
suma módulo al número de cajones. En la Figura 12.21 
se muestra la aplicación de este esquema, utilizando 10 
cajones, para el archivo cuenta , bajo la suposición de 
que la letra í-ésima del alfabeto está representada por 
el número entero i. 

Las funciones de asociación requieren un diseño cui¬ 
dadoso. Una mala función de asociación podría provo¬ 
car que una búsqueda tome un tiempo proporcional al 
número de claves de búsqueda en el archivo. Una fun¬ 
ción bien diseñada en un caso medio de búsqueda toma 
un tiempo constante (pequeño), independiente del núme¬ 
ro de claves búsqueda en el archivo. 
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Cajón 0 Cajón 5 



FIGURA 12.21. Organización asociativa del archivo cuenta utilizando nombre-sucursal como clave. 


12.5.1.2. Gestión de desbordamientos 
de cajones 

Hasta ahora se ha asumido que cuando se inserta un 
registro, el cajón al que se asigna tiene espacio para 
almacenar el registro. Si el cajón no tiene suficiente 
espacio, sucede lo que se denomina desbordamiento 
de cajones. Los desbordamientos de cajones pueden 
ocurrir por varias razones: 

• Cajones insuficientes. El número de cajones, que 
se denota con n B , debe ser escogido tal que n c > n r 
/ f r , donde n r denota el número total de registros 
que serán almacenados, y f. denota el número de 
registros que se colocarán en un cajón. Esta desig¬ 
nación, por supuesto, está bajo la suposición de 
que se conoce el número total de registros cuando 
se define la función de asociación. 

• Atasco. Algunos cajones tienen asignados más 
registros que otros, por lo que un cajón se podría 


desbordar incluso cuando otros cajones tienen toda¬ 
vía espacio. Esta situación se denomina atasco de 
cajones. El atasco puede ocurrir por dos razones: 

1. Varios registros podrían tener la misma clave 
de búsqueda. 

2. La función de asociación elegida podría pro¬ 
ducir una distribución no uniforme de las cla¬ 
ves de búsqueda. 

Para que la probabilidad de desbordamiento de cajo¬ 
nes se reduzca, se escoge el número de cajones igual a 
(n r /f r )*( 1 + d), donde d es un factor normalmente con 
un valor cercano a 0,2. Se pierde algo de espacio: alre¬ 
dedor del 20 por ciento del espacio en los cajones esta¬ 
rá vacío. Pero el beneficio es que la probabilidad de des¬ 
bordamiento se reduce. 

A pesar de la asignación de unos pocos más de cajo¬ 
nes de los requeridos, el desbordamiento de cajones toda¬ 
vía puede suceder. Trataremos el desbordamiento de cajo- 
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nes utilizando cajones de desbordamiento. Si un regis¬ 
tro se tiene que insertar en un cajón cy c está ya lleno, 
se proporcionará un cajón de desbordamiento para c y 
el registro se insertará en el cajón de desbordamiento. Si 
el cajón de desbordamiento está también lleno, se pro¬ 
porcionará otro cajón de desbordamiento, y así sucesi¬ 
vamente. Todos los cajones de desbordamiento de un 
cajón determinado están encadenados juntos en una lis¬ 
ta enlazada, como se muestra en la Figura 12.22. El tra¬ 
tamiento del desbordamiento utilizando una lista enla¬ 
zada se denomina cadena de desbordamiento. 

Se debe variar un poco el algoritmo de búsqueda para 
tratar la cadena de desbordamiento. Como se dijo antes, 
la función de asociación se emplea sobre la clave de 
búsqueda para identificar un cajón c. Luego se exami¬ 
nan todos los registros en el cajón c para ver si coinci¬ 
den con la clave búsqueda, como antes. Además, si el 
cajón c tiene cajones de desbordamiento, los registros 
en todos los cajones de desbordamiento de c se tienen 
que examinar también. 

La forma de la estructura asociativa que se acaba de 
describir se denomina algunas veces asociación cerra¬ 
da. Bajo una aproximación alternativa, llamada aso¬ 
ciación abierta, se fija el conjunto de cajones y no hay 
cadenas de desbordamiento. Por el contrario, si un cajón 
está lleno, los registros se insertan en algún otro cajón 
del conjunto inicial C de cajones. Una política es utili¬ 
zar el siguiente cajón (en orden cíclico) que tenga espa¬ 
cio; esta política se llama ensayo lineal. Se utilizan tam¬ 
bién otras políticas, tales como el cálculo funciones de 
asociación adicionales. La asociación abierta se emplea 
en la construcción de tablas de símbolos para compila¬ 
dores y ensambladores, aunque es preferible la asocia¬ 
ción cerrada para los sistemas de bases de datos. La 
razón es que el borrado bajo la asociación abierta es cos¬ 
toso. Normalmente, los compiladores y ensambladores 


realizan solamente operaciones de búsqueda e inserción 
en sus tablas de símbolos. Sin embargo, en un sistema 
de bases de datos es importante ser capaz de tratar el 
borrado tan bien como la inserción. Así, la asociativi- 
dad abierta es un aspecto de menor importancia en la 
implementación de bases de datos. 

Un inconveniente importante relativo a la forma de 
asociación que se ha descrito es que la función de aso¬ 
ciación se debe elegir cuando se implementa el sistema 
y no se puede cambiar fácilmente después si el archivo 
que se está indexando aumenta o disminuye. Ya que la 
función h asigna valores de la clave búsqueda a un con¬ 
junto fijo C de direcciones de cajón, emplearemos más 
espacio si C fue concebido para manejar el futuro cre¬ 
cimiento del archivo. Si C es demasiado pequeño, los 
cajones contienen registros de una gran variedad de valo¬ 
res de la clave búsqueda, pudiendo originar el desbor¬ 
damiento del cajón. A medida que el archivo aumenta 
el rendimiento se degrada. Se estudiará más adelante, 
en el Apartado 12.6, cómo cambiar dinámicamente el 
número de cajones y la función de asociación. 

12.5.2. índices asociativos 

La asociatividad se puede utilizar no solamente para la 
organización de archivos sino también para la creación 
de estructuras de índice. Un índice asociativo (hash 
índex) organiza las claves de búsqueda, con sus punteros 
asociados, dentro de una estructura de archivo asociati¬ 
vo. Un índice asociativo se construye como se indica a 
continuación. Primero se aplica una función de asocia¬ 
ción sobre la clave de búsqueda para identificar un cajón, 
luego se almacenan la clave y los punteros asociados en 
el cajón (o en los cajones de desbordamiento). En la Figu¬ 
ra 12.23 se muestra un índice asociativo secundario en 
el archivo cuenta para la clave de búsqueda número-cuen- 


Cajón 0 


Cajón 1 


Cajón 2 


Cajón 3 


cajones de desbordamiento para el cajón 1 


FIGURA 12.22. Cadena de desbordamiento en una estructura asociativa. 
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ta. La función de asociación utilizada calcula la suma de 
los dígitos del número de cuenta módulo siete. El índice 
asociativo tiene siete cajones, cada uno de tamaño dos 
(los índices realistas tendrían, por supuesto, tamaños de 
los cajones más grandes). Uno de los cajones tiene tres 
claves asignadas a él, por lo que tiene un cajón de des¬ 
bordamiento. En este ejemplo, número-cuenta es una cla¬ 
ve primaria para cuenta, así que cada clave de búsqueda 
tiene solamente un puntero asociado. En general se pue¬ 
den asociar múltiples punteros con cada clave. 

Se usa el término índice asociativo para denotar 
las estructuras de archivo asociativo, así como los 


índices secundarios asociativos. Estrictamente hablan¬ 
do, los índices asociativos son sólo estructuras de índi¬ 
ces secundarios. Un índice asociativo nunca necesita 
una estructura de índice primario, ya que si un archi¬ 
vo está organizado utilizando asociatividad, no hay 
necesidad de una estructura de índice asociativo sepa¬ 
rada. Sin embargo, ya que la organización de archi¬ 
vos asociativos proporciona el mismo acceso directo 
a registros que se proporciona con la indexación, se 
pretende que la organización de un archivo mediante 
asociación también tenga un índice primario asocia¬ 
tivo virtual en él. 


12.6. ASOCIACIÓN DINÁMICA 


Como se ha visto, la necesidad de fijar el conjunto C 
de direcciones de cajón presenta un problema serio 
con la técnica de asociación estática vista en el Apar¬ 
tado anterior. La mayoría de las bases de datos crecen 
con el tiempo. Si se va a utilizar la asociación estáti¬ 


ca para estas bases de datos, tenemos tres clases de 
opciones: 

1. Elegir una función de asociación basada en el 
tamaño actual del archivo. Esta opción produci- 


Cajón 0 


Cajón 1 


C-215 


C-305 



Cajón 2 


Cajón 3 


Cajón 4 


Cajón 5 


Cajón 6 


C-101 


C-110 



C-217 



C-201 


C-1 02 






C-218 





C-222 






C-217 

Barcelona 

750 

C-101 

Daimiel 

500 

C-1 10 

Daimiel 

600 

C-215 

Madrid 

700 

C-1 02 

Pamplona 

400 

C-201 

Pamplona 

900 

C-218 

Pamplona 

700 

C-222 

Reus 

700 

C-305 

Ronda 

350 


FIGURA 12.23. Indice asociativo de la clave de búsqueda número-cuenta del archivo cuenta. 
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rá una degradación del rendimiento a medida que 
la base de datos crezca. 

2. Elegir una función de asociación basada en el 
tamaño previsto del archivo con relación a un pun¬ 
to determinado del futuro. Aunque se evite la 
degradación del rendimiento, inicialmente puede 
que se pierda una cantidad de espacio significante. 

3. Reorganizar periódicamente la estructura asocia¬ 
tiva en respuesta al crecimiento del archivo. Esta 
reorganización implica elegir una nueva función 
de asociación, volviendo a calcular la función de 
asociación de cada registro en el archivo y gene¬ 
rando nuevas asignaciones de los cajones. Esta 
reorganización es una operación masiva que requie¬ 
re mucho tiempo. Además, es necesario prohibir 
el acceso al archivo durante la reorganización. 

Algunas técnicas de asociación dinámica permiten 
modificar la función de asociación dinámicamente para 
acomodarse al aumento o disminución de la base de 
datos. Describiremos una forma de asociación dinámi¬ 
ca, llamada asociación extensible. Las notas biblio¬ 
gráficas proporcionan referencias a otras formas de aso- 
ciatividad dinámica. 

12.6.1. Estructura de datos 

La asociación extensible hace frente a los cambios del 
tamaño de la base de datos dividiendo y fusionando los 
cajones a medida que la base de datos aumenta o dis¬ 
minuye. Como resultado se conserva eficazmente el 
espacio. Por otra parte, puesto que la reorganización se 
realiza sobre un cajón cada vez, la degradación del ren¬ 
dimiento resultante es aceptablemente baja. 


Con la asociación extensible se elige una función de 
asociación h con las propiedades deseadas de unifor¬ 
midad y aleatoriedad. Sin embargo, esta función de aso¬ 
ciación genera valores dentro de un rango relativamen¬ 
te amplio, llamado, enteros binarios de b bits. Un valor 
normal de b es 32. 

No se crea un cajón para cada valor de la función de 
asociación. De hecho, 2 32 está por encima de 4 billones 
y no sería razonable crear tantos cajones salvo para las 
mayores bases de datos. Por el contrario, se crean tan¬ 
tos cajones bajo demanda, esto es, tantos como regis¬ 
tros haya insertados en el archivo. Inicialmente no se 
utiliza el total de b bits del valor de la función de aso¬ 
ciación. En cualquier caso, empleamos i bits, donde 0 
< i <b. Estos i bits son utilizados como desplazamien¬ 
to en una tabla adicional con las direcciones de los cajo¬ 
nes. El valor de i aumenta o disminuye con el tamaño 
de la base de datos. 

En la Figura 12.24 se muestra una estructura gene¬ 
ral de asociación extensible. La i que aparece en la figu¬ 
ra encima de la tabla de direcciones de los cajones indi¬ 
ca que se requieren i bits de la función de asociación 
h(K) para determinar el cajón apropiado para K. Obvia¬ 
mente, este número cambiará a medida que el archivo 
aumente. Aunque se requieren i bits para encontrar la 
entrada correcta en la tabla de direcciones de los cajo¬ 
nes, algunas entradas consecutivas de la tabla podrían 
apuntar al mismo cajón. Todas estas entradas tendrán 
un prefijo común del valor de la función de asociación, 
aunque la longitud de este prefijo podría ser menor que 
i. Por lo tanto, se asocia con cada cajón un número ente¬ 
ro que proporciona la longitud del prefijo común del 
valor de la función de asociación. En la Figura 12.24, 
el entero asociado con el cajón j aparece como L. El 



tabla de direcciones de los cajones 



FIGURA 12.24. Estructura asociativa general extensible. 
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número de entradas en la tabla de direcciones de cajo¬ 
nes que apuntan al cajón j es: 

2 (, '-9 

12.6.2. Consultas y actualizaciones 

Ahora se verá cómo realizar la búsqueda, la inserción 
y el borrado en una estructura asociativa extensible. 

Para localizar el cajón que contiene el valor de la cla¬ 
ve de búsqueda K„ se toman los primeros i bits más sig¬ 
nificativos de h(K¡), se busca la entrada de la tabla que 
corresponda a esta cadena de bits, y se sigue el punte¬ 
ro del cajón en la entrada de la tabla. 

Para insertar un registro con un valor de la clave 
de búsqueda K, se sigue el mismo procedimiento de 
búsqueda que antes, llegando a algún cajón j. Si hay 
sitio en el cajón se inserta el registro en el cajón. Si 
por el contrario el cajón está lleno, hay que dividir el 
cajón y redistribuir los registros actuales más uno 
nuevo. Para dividir el cajón, primero hay que deter¬ 
minar del valor de la función de asociación por si fue¬ 
ra necesario incrementar el número de bits que se están 
usando. 

• Sil = ij, entonces solamente una entrada en la tabla 
de direcciones de los cajones apunta al cajón j. Por 
tanto, es necesario incrementar el tamaño de la 
tabla de direcciones de los cajones para incluir los 
punteros a los dos cajones que resultan de la divi¬ 
sión del cajón j. Esto se hace considerando un bit 
adicional en el valor de la función de asociación. 
Luego se incrementa el valor de i en uno, dupli¬ 
cando el tamaño de la tabla de direcciones de cajo¬ 
nes. Cada entrada se sustituye por dos entradas, 
cada una de las cuales con el mismo puntero que 
la entrada original. Ahora dos entradas en la tabla 
de direcciones de cajones apuntan al cajón j. Así 
pues, se asigna un nuevo cajón (cajón z) y hace¬ 
mos que la segunda entrada apunte al nuevo cajón. 
Se pone i ■ e i z a i. A continuación se vuelve a cal¬ 
cular la función de asociación para cada registro 
del cajón j y, dependiendo de los primeros i bits 
(recuérdese que se ha añadido uno a i), se man¬ 
tiene en el cajón j o se coloca en el cajón recién 
creado. 

Ahora se vuelve a intentar la inserción del nue¬ 
vo registro. Normalmente el intento tiene éxito. 
Sin embargo, si todos los registros del cajón j, así 
como el nuevo registro, tienen el mismo prefijo 
del valor de la función de asociación, será nece¬ 
sario dividir el cajón de nuevo, ya que todos los 
registros en el cajón j y el nuevo registro tienen 
asignados el mismo cajón. Si la función de aso¬ 
ciación se eligió cuidadosamente, es poco proba¬ 
ble que una simple inserción provoque que un 
cajón se divida más de una vez, a menos que haya 
un gran número de registros con la misma clave 


de búsqueda. Si todos los registros en el cajón j 
tienen el mismo valor de la clave de búsqueda, 
ningún número de divisiones servirá. En estos 
casos se usan cajones de desbordamiento para 
almacenar los registros, como en la asociación 
estática. 

• Si i > ij, entonces más de una entrada en la tabla 
de direcciones de cajones apunta al cajón j. Así, 
se puede dividir el cajón j sin incrementar el tama¬ 
ño de la tabla de direcciones. Obsérvese que todas 
las entradas que apuntan al cajón j corresponden 
a prefijos del valor de la función de asociación que 
tienen el mismo valor en los ij bits más a la izquier¬ 
da. Se asigna un nuevo cajón (cajón z) y se pone 
ij e i, al valor que resulta de añadir uno al valor i ■ 
original. A continuación, es necesario ajustar las 
entradas en la tabla de direcciones de cajones que 
anteriormente apuntaban al cajón j. (Nótese que 
con el nuevo valor de /■ no todas las entradas 
corresponden a prefijos del valor de la función de 
asociación que tienen el mismo valor en los i-bits 
más a la izquierda). La primera mitad de todas las 
entradas se dejan como estaban (apuntando al 
cajón j) y el resto de entradas se ponen apuntan¬ 
do al cajón recién creado (cajón z). Por último, 
como en el caso anterior, se vuelve a calcular la 
función de asociación para cada registro en el 
cajón j y se colocan o bien en el cajón j o bien en 
el cajón z recién creado. 

Luego se vuelve a intentar la inserción. En el 
caso poco probable de que vuelva a fallar, se apli¬ 
ca uno de los dos casos, i = i¡ o i > q, según sea lo 
apropiado. 

Nótese que en ambos casos sólo se necesita recalcular 
la función de asociación en los registros del cajón j. 

Para borrar un registro con valor de la clave de bús¬ 
queda K¡ se sigue el mismo procedimiento de búsque¬ 
da anterior, finalizando en algún cajón, llamémosle j. 
Se borran ambos, el registro del archivo y la clave de 
búsqueda del cajón. El cajón también se elimina si se 
queda vacío. Nótese que en este momento, varios cajo¬ 
nes se pueden fusionar, reduciendo el tamaño de la tabla 
de direcciones de cajones a la mitad. El procedimiento 
para decidir cuándo y cómo fusionar cajones se deja 
como un ejercicio a realizar. Las condiciones bajo la 
que la tabla de direcciones de cajones se puede reducir 
de tamaño también se dejan como ejercicio. A diferen¬ 
cia de la fusión de cajones, el cambio de tamaño de la 
tabla de direcciones de cajones es una operación muy 
costosa si la tabla es grande. Por tanto, sólo sería acon¬ 
sejable reducir el tamaño de la tabla de direcciones de 
cajones si el número de cajones se reduce considera¬ 
blemente. 

El ejemplo del archivo cuenta en la Figura 12.25 ilus¬ 
tra la operación de inserción. Los valores de la función 
de asociación de 32 bits para nombre-sucursal se mues- 


304 


CAPÍTULO 12 INDEXACIÓN Y ASOCIACIÓN 


C-217 

Barcelona 

750 

C-101 

Daimiel 

500 

C-110 

Daimiel 

600 

C-215 

Madrid 

700 

C-102 

Pamplona 

400 

C-201 

Pamplona 

900 

C-218 

Pamplona 

700 

C-222 

Reus 

700 

C-305 

Ronda 

350 


FIGURA 12.25. Archivo de ejemplo cuenta. 


tran en la Figura 12.26. Se asume que inicialmente el 
archivo está vacío, como se muestra en la Figura 12.27. 
Insertaremos los registros de uno en uno. Para mostrar 
todas las características de la asociación extensible se 
empleará una estructura pequeña y se hará la suposi¬ 
ción no realista de que un cajón sólo puede contener dos 
registros. 

Vamos a insertar el registro (C-217, Barcelona, 750). 
La tabla de direcciones de cajones contiene un puntero 
al único cajón donde se inserta el registro. A continua¬ 
ción, insertamos el registro (C-101, Daimiel, 500). Este 
registro también se inserta en el único cajón de la estruc¬ 
tura. 

Cuando se intenta insertar el siguiente registro (C- 
110, Daimiel, 600), nos encontramos con que el cajón 
está lleno. Ya que i = i 0 , es necesario incrementar el 
número de bits que se toman del valor de la función de 
asociación. Ahora se utiliza un bit, permitiendo 2 1 = 2 
cajones. Este incremento en el número de bits necesa¬ 
rios duplica el tamaño de la tabla de direcciones de cajo¬ 


nes a dos entradas. Se continúa con la división del cajón, 
colocando en el nuevo cajón aquellos registros cuya cla¬ 
ve de búsqueda tiene un valor de la función de asocia¬ 
ción que comienza por 1 y dejando el resto de registros 
en el cajón original. En la Figura 12.28 se muestra el 
estado de la estructura después de la división. 

A continuación insertamos (C-215, Madrid, 700). Ya 
que el primer bit de //(Madrid) es 1, se tiene que inser¬ 
tar este registro en el cajón apuntado por la entrada «1» 
en la tabla de direcciones de cajones. Una vez más, nos 
encontramos con el cajón lleno e i = i,. Se incrementa 
el número de bits que se usan del valor de la función de 
asociación a dos. Este incremento en el número de bits 
necesarios duplica el tamaño de la tabla de direcciones 
de cajones a cuatro entradas, como se muestra en la 
Figura 12.29. Como el cajón con el prefijo 0 del valor 
de la función de asociación de la Figura 12.28 no se 
dividió, las dos entradas de la tabla de direcciones 00 y 
01 apuntan a este cajón. 

Para cada registro en el cajón de la Figura 12.28 con 
prefijo 1 del valor de la función de asociación (el cajón 
que se dividió) se examinan los dos primeros bits del 
valor de la función de asociación para determinar qué 
cajón de la nueva estructura le corresponde. 

Proseguimos insertando el registro (C-102, Pamplo¬ 
na, 400), el cual se aloja en el mismo cajón que Madrid. 
La siguiente inserción, la de (C-201, Pamplona, 900), 
provoca un desbordamiento en un cajón, produciendo 
el incremento del número de bits y la duplicación del 
tamaño de la tabla de direcciones de cajones. La inser¬ 
ción del tercer registro de Pamplona (C-218, Pamplo¬ 
na, 700) produce otro desbordamiento. Sin embargo, 
este desbordamiento no se puede resolver incremen¬ 
tando el número de bits, ya que los tres registros tienen 


nombre-sucursal 

h (nombre-sucursal) 

Barcelona 

0010 1101 1111 1011 0010 1100 0011 0000 

Daimiel 

1010 0011 1010 0000 1100 0110 1001 1111 

Madrid 

1100 0111 1110 1101 1011 1111 0011 1010 

Pamplona 

1111 0001 0010 0100 1001 0011 0110 1101 

Reus 

0011 0101 1010 0110 1100 1001 1110 1011 

Ronda 

1101 1000 0011 1111 1001 1100 0000 0001 


FIGURA 12.26. Función de asociación para nombre-sucursal. 


prefijo asociativo 
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tabla de direcciones de los cajones 
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cajón 1 


FIGURA 12.27. Estructura asociativa extensible inicial. 
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Barcelona 
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C-101 

Daimiel 

500 

C-110 
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600 


FIGURA 12.28. Estructura asociativa después de tres inserciones. 


exactamente el mismo valor de la función de asocia¬ 
ción. Por tanto, se utiliza un cajón de desbordamiento, 
como se muestra en la Figura 12.30. 

Se continúa de esta manera hasta que se insertan 
todos los registros del archivo cuenta de la Figura 
12.24. La estructura resultante se muestra en la Figu¬ 
ra 12.31. 

12.6.3. Comparaciones con otros esquemas 

Examinemos a continuación las ventajas e inconve¬ 
nientes de la asociación extensible frente a otros esque¬ 
mas ya discutidos. La ventaja principal de la asociación 


extensible es que el rendimiento no se degrada según 
crece el archivo. Además de esto, el espacio adicional 
requerido es mínimo. Aunque la tabla de direcciones de 
cajones provoca un gasto adicional, sólo contiene un 
puntero por cada valor de la función de asociación con 
la longitud del prefijo actual. De esta manera el tama¬ 
ño de la tabla es pequeño. El principal ahorro de espa¬ 
cio de la asociación extensible sobre otras formas de 
asociación es que no es necesario reservar cajones para 
un futuro crecimiento; en vez de ello se pueden asignar 
los cajones de manera dinámica. 

Un inconveniente de la asociación extensible es que 
la búsqueda implica un nivel adicional de indirección, 
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FIGURA 12.29. Estructura asociativa después de cuatro inserciones. 
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FIGURA 12.30. Estructura asociativa después de siete inserciones. 
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FIGURA 12.31. Estructura asociativa extensible para el archivo cuenta. 
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ya que se debe acceder a la tabla de direcciones de los 
cajones antes que acceder al propio cajón. Esta refe¬ 
rencia extra tiene una repercusión menor en el rendi¬ 
miento. Aunque las estructuras asociativas que se dis¬ 
cutieron con anterioridad no tienen este nivel extra de 
indirección, pierden su leve ventaja en el rendimiento 
cuando se llenan. 

Por tanto, la asociación extensible se muestra como 
un técnica muy atractiva teniendo en cuenta que se 


acepta la complejidad añadida en su implementación. 
En las notas bibliográficas se proporcionan descrip¬ 
ciones más detalladas sobre la implementación de la 
asociación extensible. Las notas bibliográficas tam¬ 
bién tienen referencias a otra forma de asociación diná¬ 
mica llamada asociación lineal, la cual evita el nivel 
extra de indirección asociado con la asociación exten¬ 
sible y el posible coste de más cajones de desborda¬ 
miento. 


12.7. COMPARACIÓN DE LA INDEXACIÓN ORDENADA Y LA ASOCIACIÓN 


Se han visto varios esquemas de indexación ordenada y 
varios esquemas de asociación. Se pueden organizar los 
archivos de registros como archivos ordenados, utilizan¬ 
do una organización de índice secuencial o usando orga¬ 
nizaciones de árbol B + . Alternativamente se pueden orga¬ 
nizar los archivos usando asociación. Finalmente, podemos 
organizar los archivos como montículos, donde los regis¬ 
tros no están ordenados de ninguna manera en particular. 

Cada esquema tiene sus ventajas dependiendo de la 
situación. Un implementador de un sistema de bases de 
datos podría proporcionar muchos esquemas, dejando 
al diseñador de la base de datos la decisión final de qué 
esquemas utilizar. Sin embargo, esta aproximación 
requiere que el implementador escriba más código, 
aumentando así el coste del sistema y el espacio que 
éste ocupa. Por tanto, la mayoría de los sistemas usan 
solamente unos pocos o sólo una forma de organización 
asociativa de archivos o índices asociativos. 

Para hacer una sabia elección, el implementador o el 
diseñador de la base de datos debe considerar los 
siguientes aspectos: 

• ¿Es aceptable el coste de una reorganización perió¬ 
dica del índice o de una estructura asociativa? 

• ¿Cuál es la frecuencia relativa de las inserciones 
y borrados? 

• ¿Es deseable mejorar el tiempo medio de acceso 
a expensas de incrementar el tiempo de acceso en 
el peor de los casos? 

• ¿Qué tipos de consultas se supone que van a rea¬ 
lizar los usuarios? 

De estos puntos ya se han examinado los tres prime¬ 
ros, comenzando con la revisión de las ventajas relativas 
de las distintas técnicas de indexación y otra vez en la 
discusión de las técnicas de asociación. El cuarto punto, 
el tipo esperado de la consulta, es un aspecto crítico para 
la elección entre la indexación ordenada o la asociación. 

Si la mayoría de las consultas son de la forma: 

select A¡, Á 2 , ..., A n 

from r 
where A¡ = c 


entonces, para procesar esta consulta, el sistema reali¬ 
zará una búsqueda en un índice ordenado o en una 
estructura asociativa de un atributo A¡ con el valor c. 
Para este tipo de consultas es preferible un esquema aso¬ 
ciativo. Una búsqueda en un índice ordenado requiere 
un tiempo proporcional al logaritmo del número de valo¬ 
res para A¡ en r. Sin embargo, en una estructura asocia¬ 
tiva, el tiempo medio de una búsqueda es una constan¬ 
te que no depende del tamaño de la base de datos. La 
única ventaja de un índice sobre una estructura asocia¬ 
tiva con este tipo de consulta es que el tiempo de una 
búsqueda en el peor de los casos es proporcional al loga¬ 
ritmo del número de valores para A¡ en r. Por el con¬ 
trario, si se utiliza una estructura asociativa, el tiempo 
de una búsqueda en el peor de los casos es proporcio¬ 
nal al número de valores para A¡ en r. Sin embargo, al 
ser poco probable el peor caso de búsqueda (mayor tiem¬ 
po de búsqueda) con la asociación, es preferible usar en 
este caso una estructura asociativa. 

Las técnicas de índices ordenados son preferibles a 
las estructuras asociativas en los casos donde la con¬ 
sulta especifica un rango de valores. Estas consultas tie¬ 
nen el siguiente aspecto: 

select A,, A 2 , ..., A n 

from r 

where A¡ < c 2 and A, > c¡ 

En otras palabras, la consulta anterior encuentra todos 
los registros A, con valores entre c ¡ y c 2 . 

Consideremos cómo procesar esta consulta usando 
un índice ordenado. Primero se realiza una búsqueda en 
el valor c¡. Una vez que se ha encontrado un cajón que 
contiene el valor c¡, se sigue la cadena de punteros en 
el índice en orden para leer el siguiente cajón y conti¬ 
nuamos de esta manera hasta encontrar c 2 . 

Si en vez de un índice ordenado se tiene una estruc¬ 
tura asociativa, se puede realizar una búsqueda en c , y 
localizar el correspondiente cajón, pero en general no 
es fácil determinar el siguiente cajón que se tiene que 
examinar. La dificultad surge porque una buena función 
de asociación asigna valores aleatoriamente a los cajo¬ 
nes. Por tanto, no existe la noción del «siguiente cajón 
en el orden». La razón por la que no se pueden encade- 
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nar cajones juntos según cierto orden en A¡ es que cada 
cajón tiene asignado muchos valores de la clave de bús¬ 
queda. Ya que los valores están diseminados aleatoria¬ 
mente según la función de asociación, es muy probable 
que el rango de valores esté esparcido a través de 
muchos cajones o tal vez en todos. Por esta razón se tie¬ 
nen que leer todos los cajones para encontrar las claves 
de búsqueda requeridas. 


Normalmente se usa la indexación ordenada, a menos 
que se sepa de antemano que las consultas sobre un ran¬ 
go de valores van a ser poco frecuentes, en cuyo caso 
se utiliza la asociación. Las organizaciones asociativas 
son particularmente útiles para archivos temporales 
creados durante el procesamiento de consultas, siempre 
que se realicen búsquedas basadas en un valor de la cla¬ 
ve, pero no consultas de rangos. 


12.8. DEFINICIÓN DE ÍNDICES EN SQL 


La norma SQL no proporciona al usuario o adminis¬ 
trador de la base de datos ninguna manera de contro¬ 
lar qué índices se crean y se mantienen por el sistema 
de base de datos. Los índices no se necesitan para la 
corrección, ya que son estructuras de datos redundan¬ 
tes. Sin embargo, los índices son importantes para el 
procesamiento eficiente de las transacciones, inclu¬ 
yendo las transacciones de actualización y consulta. 
Los índices son también importantes para un cumpli¬ 
miento eficiente de las ligaduras de integridad. Por 
ejemplo, las implementaciones típicas obligan a decla¬ 
rar una clave (Capítulo 6) mediante la creación de un 
índice con la clave declarada como la clave de bús¬ 
queda del índice. 

En principio, un sistema de base de datos puede deci¬ 
dir automáticamente qué índices crear. Sin embargo, 
debido al coste en espacio de los índices, así como el 
efecto de los índices en el procesamiento de actualiza¬ 
ciones, no es fácil hacer una elección apropiada auto¬ 
máticamente sobre qué índices mantener. Por este moti¬ 
vo, la mayoría de las implementaciones de SQL 
proporcionan al programador control sobre la creación 
y eliminación de índices vía órdenes del lenguaje de 
definición de datos. 

A continuación se ilustrará las sintaxis de estas órde¬ 
nes. Aunque la sintaxis que se muestra se usa amplia¬ 
mente y está soportada en muchos sistemas de bases de 
datos, no es parte de la norma SQL: 1999. Las normas 
SQL (hasta SQL: 1999, al menos) no dan soporte al con¬ 
trol del esquema físico de la base de datos y aquí nos 
limitaremos al esquema lógico de la base de datos. 

Un índice se crea mediante la orden create Índex, la 
cual tiene la forma 


create índex <nombre-índice> on <nombre-relación> 
(<lista-atributos>) 

lista-atributos es la lista de atributos de la relación que 
constituye la clave de búsqueda del índice. 

Para definir un índice llamado índice-s de la relación 
sucursal con la clave de búsqueda nombre-sucursal, se 
escribe 

create índex índice-s on sucursal ( nombre-sucursal ) 

Si deseamos declarar que la clave de búsqueda es 
una clave candidata, hay que añadir el atributo unique 
a la definición del índice. Con esto, la orden 

create unique índex índice-s on sucursal 
(, nombre-sucursal) 

declara nombre-sucursal como una clave candidata de 
sucursal. Si cuando se introduce la orden create uni¬ 
que índex, nombre-sucursal no es una clave candida¬ 
ta, se mostrará un mensaje de error y el intento de cre¬ 
ar un índice fallará. Por otro lado, si el intento de crear 
el índice ha tenido éxito, cualquier intento de insertar 
una tupia que viole la declaración de clave fallará. Hay 
que observar que el carácter unique es redundante si la 
declaración unique de SQL estándar se soporta en el 
sistema de base de datos. 

El nombre de índice especificado con el índice se 
necesita para hacer posible la eliminación ( drop ) de índi¬ 
ces. La orden drop índex tiene la forma 

drop índex <nombre-índice> 


12.9. ACCESOS MULTICLAVE 


Hasta ahora se ha asumido implícitamente que se utili- 12.9.1. Uso de varios índices de clave única 
za solamente un índice (o tabla asociativa) para proce¬ 
sar una consulta en una relación. Sin embargo, para cier¬ 
tos tipos de consultas es ventajoso el uso de múltiples 
índices si éstos existen. 
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Asumamos que el archivo cuenta tiene dos índices: uno 
para el nombre-sucursal y otro para saldo. Considere¬ 
mos la consulta : «Encontrar todos los números de cuen- 
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ta de la sucursal Pamplona con saldos igual a 1.000 €». 
Se escribe 

select número-préstamo 
from cuenta 

where nombre-sucursal = «Pamplona» and 
saldo = 1000 

Hay tres estrategias posibles para procesar esta consulta: 

1. Usar el índice en nombre-sucursal para encontrar 
todos los registros pertenecientes a la sucursal de 
Pamplona. Luego se examinan estos registros para 
ver si saldo = 1.000. 

2. Usar el índice en saldo para encontrar todos los 
registros pertenecientes a cuentas con saldos de 
1.000 €. Luego se examinan estos registros para 
ver si nombre-sucursal = «Pamplona.» 

3. Usar el índice en nombre-sucursal para encontrar 
punteros a registros pertenecientes a la sucursal 
Pamplona. Y también usar el índice en saldo para 
encontrar los punteros a todos los registros per¬ 
tenecientes a cuentas con un saldo de 1.000. Se 
realiza la intersección de estos dos conjuntos de 
punteros. Aquellos punteros que están en la inter¬ 
sección apuntan a los registros pertenecientes a 
la vez a Pamplona y a las cuentas con un saldo de 
1.000 €. 

La tercera estrategia es la única de las tres que aprove¬ 
cha la ventaja de tener varios índices. Sin embargo, 
incluso esta estrategia podría ser una pobre elección si 
sucediera lo siguiente: 

• Hay muchos registros pertenecientes a la sucursal 
Pamplona. 

• Hay muchos registros pertenecientes a cuentas con 
un saldo de 1.000 €. 

• Hay solamente unos cuantos registros pertene¬ 
cientes a ambos, a la sucursal Pamplona y a las 
cuentas con un saldo de 1.000 €. 

Si estas condiciones ocurrieran, se tendrían que exami¬ 
nar un gran número de punteros para producir un resul¬ 
tado pequeño. La estructura de índices denominada 
«índice de mapas de bits» acelera significativamente la 
operación de inserción usada en la tercera estrategia. 
Los índices de mapas de bits se describen en el Aparta¬ 
do 12.9.4. 

12.9.2. índices sobre varias claves 

Una estrategia más eficiente para este caso es crear y uti¬ 
lizar un índice con una clave de búsqueda ( nombre-sucur¬ 
sal , scddo), esto es, la clave de búsqueda consistente en 
el nombre de la sucursal concatenado con el saldo de la 
cuenta. La estructura del índice es la misma que para 


cualquier otro índice, con la única diferencia de que la 
clave de búsqueda no es un simple atributo sino una lis¬ 
ta de atributos. La clave de búsqueda se puede repre¬ 
sentar como una tupia de valores, de la forma (a u ..., a„), 
donde los atributos indexados son A,,..., A n . El orden de 
los valores de la clave de búsqueda es el orden lexico¬ 
gráfico. Por ejemplo, para el caso de dos atributos en la 
clave de búsqueda, (a u a 2 ) < (a u afi si a x < a 2 , o bien 
a { = y a 2 < b 2 . El orden lexicográfico es básicamente 
el mismo orden alfabético de las palabras. 

El empleo de una estructura de índice ordenado con 
múltiples atributos tiene algunas deficiencias. Como 
ilustración considérese la consulta 

select número-préstamo 
from cuenta 

where nombre-sucursal < «Pamplona» and 
saldo = 1000 

Se puede responder a esta consulta usando un índice 
ordenado con la clave de búsqueda ( nombre-sucursal , 
saldo) de la manera siguiente: para cada valor de nom¬ 
bre-sucursal que es menor que «Pamplona» alfabética¬ 
mente localizar los registros con un saldo de 1.000. Sin 
embargo, debido a la ordenación de los registros en el 
archivo, es probable que cada registro esté en un blo¬ 
que diferente de disco, causando muchas operaciones 
de E/S. 

La diferencia entre esta consulta y la anterior es que 
la condición en nombre-sucursal es una condición de 
comparación, en vez de una condición de igualdad. 

Para acelerar el procesamiento en general de con¬ 
sultas con varias claves de búsqueda (las cuales pueden 
implicar una o más operaciones de comparación) se pue¬ 
den emplear varias estructuras especiales. Se conside¬ 
rará la estructura de archivos en retícula en el Aparta¬ 
do 12.9.3. Hay otra estructura, denominada árbol R, que 
también se puede usar para este propósito. El árbol R 
es una extensión que se usa fundamentalmente con tipos 
de datos geográficos y se pospone su descripción hasta 
el Capítulo 23. 

12.9.3. Archivos en retícula 

En la Figura 12.32 se muestra una parte de un archivo 
en retícula para las claves de búsqueda nombre-sucur¬ 
sal y saldo en el archivo cuenta. El array bidimensio- 
nal de la figura se llama array en retícula y los arrays 
unidimensionales se llaman escalas lineales. El archivo 
en retícula tiene un único array en retícula y una escala 
lineal para cada atributo de la clave de búsqueda. 

Las claves de búsqueda se asignan a las celdas como 
se describe a continuación. Cada celda en el array en 
retícula tiene un puntero a un cajón que contiene valo¬ 
res de las claves de búsqueda y punteros a los registros. 
Sólo se muestran en la figura algunos de los cajones y 
punteros desde las celdas. Para conservar espacio se per¬ 
mite que varios elementos del array puedan apuntar al 
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FIGURA 12.32. Archivo de rejilla para las claves nombre-sucursal y saldo del archivo cuenta. 


mismo cajón. Los recuadros punteados de la figura seña¬ 
lan las celdas que apuntan al mismo cajón. 

Supongamos que se quiere insertar en el índice de 
archivo en retícula un registro cuyo valor de la clave es 
(«Barcelona», 500.000). Para encontrar la celda asig¬ 
nada a esta clave se localizan por separado la fila y la 
columna de la celda correspondiente. 

Primero se utilizan las escalas lineales en nombre- 
sucursal para localizar la fila de la celda asignada a la 
clave de búsqueda. Para ello se busca en el array para 
encontrar el menor elemento que es mayor que «Bar¬ 
celona». En este caso es el primer elemento, así que la 
fila asignada a la clave de búsqueda es la 0. Si fuera el 
í-ésimo elemento, la clave de búsqueda se asignaría a 
la fila í-1. Si la clave de búsqueda es mayor o igual que 
todos los elementos de la escala lineal, se le asignaría 
la última fila. A continuación se utiliza la escala lineal 
en saldo para encontrar de la misma manera qué colum¬ 
na le corresponde a la clave de búsqueda. En este caso, 
el saldo 500.000 tiene asignado la columna 6. 

Por tanto, el valor de la clave de búsqueda («Bar¬ 
celona», 500.000) tiene asignado la celda de la fila 0, 
columna 6. De la misma manera («Daimiel», 60.000) 
tendría asignada la celda de la fila 1, columna 5. Ambas 
celdas apuntan al mismo cajón (como se indica con el 
recuadro punteado), así que en los dos casos los va¬ 
lores de la clave de búsqueda y el puntero al registro 
están almacenados en el cajón con la etiqueta C ; de la 
figura. 

Para realizar una búsqueda que responda a la consulta 
de nuestro ejemplo, con la condición de búsqueda 


nombre-sucursal < «Pamplona» and saldo = 1000 

buscamos todas las filas con nombres de sucursal meno¬ 
res que «Pamplona», utilizando la escala lineal de nom¬ 
bre-sucursal. En este caso, estas filas son la 0, 1 y 2. La 
fila 3 y posteriores contienen nombres de sucursal mayo¬ 
res o iguales a «Pamplona». De igual modo se obtiene 
que sólo la columna 1 puede tener un saldo de 1.000. 
En este caso sólo la columna 1 satisface esta condición. 
Así, solamente las celdas en la columna 1, filas 0, 1 y 2 
pueden contener entradas que satisfagan la condición 
de búsqueda. 

A continuación hay que examinar todas las entradas 
de los cajones apuntados por estas tres celdas. En este 
caso, solamente hay dos cajones, ya que dos de las cel¬ 
das apuntan al mismo cajón, como se indica con los 
recuadros punteados de la figura. Los cajones podrían 
contener algunas claves de búsqueda que no satisfagan 
la condición requerida, de manera que cada clave de 
búsqueda del cajón se debe comprobar de nuevo para 
averiguar si satisface la condición o no. De cualquier 
modo, solamente hay que examinar un pequeño núme¬ 
ro de cajones para responder a la consulta. 

Las escalas lineales se deben escoger de tal manera 
que los registros estén uniformemente distribuidos a tra¬ 
vés de las celdas. Si el cajón —llamémosle A— queda 
lleno y se tiene que insertar una entrada en él, se asig¬ 
na un cajón adicional B. Si más de una celda apunta a 
A, se cambian los punteros a la celda de tal manera que 
algunos apunten a A y otros a B. Las entradas en el cajón 
A y la nueva entrada se redistribuyen entre A y B basán- 
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dose en las celdas que tengan asignados. Si sólo una 
celda apunta al cajón A, B se convierte en un cajón de 
desbordamiento de A. Para mejorar el rendimiento en 
esta situación se tiene que reorganizar el archivo en retí¬ 
cula con un array en retícula extendido y escalas line¬ 
ales extendidas. Este proceso es como la expansión de 
la tabla de direcciones de los cajones en la asociación 
extensible y se deja a realizar como ejercicio. 

Es conceptualmente sencillo extender la aproxima¬ 
ción del archivo en retícula a cualquier número de cla¬ 
ves de búsqueda. Si se quiere utilizar una estructura con 
n claves hay que construir un array en retícula «-dimen¬ 
sional con n escalas lineales. 

La estructura de retícula es adecuada también para 
consultas que impliquen una sola clave de búsqueda. 
Considérese esta consulta: 

select * 

from cuenta 

where nombre-sucursal = «Pamplona» 

La escala lineal de nombre-sucursal no dice que única¬ 
mente satisfacen esta condición las celdas de la fila 3. 
Como no hay condición según el saldo, se examinan todos 
los cajones apuntados por las celdas en la fila 3 para 
encontrar las entradas pertenecientes a Pamplona. De este 
modo, se puede usar un índice de archivo en retícula con 
dos claves de búsqueda para responder consultas en cada 
clave, así como para contestar consultas en ambas cla¬ 
ves a la vez. Así un simple índice de archivo en retícula 
puede hacer el papel de tres índices distintos. Si cada índi¬ 
ce se mantuviera por separado, los tres juntos ocuparían 
más espacio y el coste de su actualización sería mayor. 

Los archivos en retícula proporcionan un descenso 
significante en el tiempo de procesamiento de consultas 
multiclave. Sin embargo, implican un gasto adicional de 
espacio (el directorio en retícula podría llegar a ser gran¬ 
de), así como una degradación del rendimiento al inser¬ 
tar y borrar registros. Además, es difícil elegir una divi¬ 
sión en los rangos de las claves para que la distribución 
de las claves sea uniforme. Si las inserciones en el archi¬ 
vo son frecuentes, la reorganización se tendrá que reali¬ 
zar periódicamente y eso puede tener un coste mayor. 

12.9.4. índices de mapas de bits 

Los índices de mapas de bits son un tipo de índices espe¬ 
cializado para la consulta sencilla sobre varias claves, 


aunqeu cada índice de mapas de bits se construya para 
una única clave. 

Para que se usen los índices de mapas de bits, los 
registros de la relación deben estar numerados secuen- 
cialmente, comenzando, digamos, en 0. Dado un núme¬ 
ro n es fácil recuperar el registro con número n. Esto es 
particularmente fácil de conseguir si los registros tie¬ 
nen un tamaño fijo y están asignados en bloques con¬ 
secutivos de un archivo. El número de registro se pue¬ 
de traducir fácilmente en un número de bloque y en un 
número que identifica el registro dentro del bloque. 

Considérese una relación r con un atributo A que 
sólo puede valer un número pequeño (por ejemplo, 
entre 2 y 20). Por ejemplo, la relación info-cliente pue¬ 
de tener un campo sexo, que puede tomar sólo los 
valores m (masculino) o f (femenino). Otro ejemplo 
podría ser el atributo nivel-ingresos, donde los ingre¬ 
sos se han dividido en 5 niveles: Ll: 0 - 9.999 €, 
L2: 10.000 - 19.999 €, L3: 20.000 - 39.999 €, L4: 
40.000 - 74.999 y L5: 75.000 - °°. Aquí, los datos ori¬ 
ginales pueden tomar muchos valores, pero un analis¬ 
ta de datos debe dividir los valores en un número 
menor de rangos para simplificar el análisis de los 
datos. 

12.9.4.1. Estructura de los índices de mapas 
de bits 

Un mapa de bits es un array de bits. En su forma más 
simple, un índice de mapas de bits sobre un atributo A 
de la relación r consiste en un mapa de bits para cada valor 
que pueda tomar A. Cada mapa de bits tiene tantos 
bits como el número de registros de la relación. El f-ési- 
mo bit del mapa de bits para el valor v¡ se establece en 1 
si el registro con número i tiene el valor Vj para el atribu¬ 
to A. El resto de bits del mapa de bits se establecen a 0. 

En nuestro ejemplo, hay un mapa de bits para el valor 
m y otro para f. El í-ésimo bit del mapa de bits para m 
se establece en 1 si el valor sexo del registro con núme¬ 
ro i es m. El resto de bits del mapa de bits para m se 
establecen en 0. Análogamente, el mapa de bits para f 
tiene el valor 1 para los bits correspondientes a los regis¬ 
tros con el valor f para el campo sexo', el resto de bits 
tienen el valor 0. La Figura 12.33 muestra un ejemplo 
de índices de mapa de bits para la relación info-cliente. 

Ahora se considerará cuándo son útiles los mapas de 
bits. La forma más simple de recuperar todos los regis¬ 
tros con el valor m (o el valor f) sería simplemente leer 


número 
de registro 

nombre 

sexo 

dirección 

nivel-ingresos 

Mapas de bits para 
sexo 

Mapas de bits para 
nivel-ingresos 

0 

Juan 

m 

Pamplona 

Ll 

m 

10010 

Ll 

10100 

1 

Diana 

f 

Barcelona 

L2 

t 

01101 

L2 

10100 

2 

María 

f 

Jaén 

Ll 



L3 

10100 

3 

Pedro 

m 

Barcelona 

L4 



L4 

10100 

4 

Katzalin 

f 

Pamplona 

L3 



L5 

10100 


FIGURA 12.33. Indices de mapas de bits para la relación info-cliente. 
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todos los registros de la relación y seleccionar los regis¬ 
tros con el valor m (o f, respectivamente). El índice de 
mapas de bits no ayuda realmente a acelerar esta selec¬ 
ción. 

De hecho, los índices de mapas de bits son útiles para 
las selecciones principalmente cuando hay selecciones 
bajo varias claves. Supóngase que se crea un índice de 
mapas de bits sobre el atributo nivel-ingresos , que se 
describió antes, además del índice de mapas de bits para 
sexo. 

Considérese ahora una consulta que seleccione muje¬ 
res con ingresos en el rango 10.000 - 19.999 €. Esta 
consulta se puede expresar como o sexo=fMúvel _ ingresos=L2 ( r). 
Para evaluar esta selección se busca el valor f en los 
mapas de bits de sexo y el valor L2 en los mapas de bits 
de nivel-ingresos, y se realiza la intersección (con¬ 
junción lógica) de los dos mapas de bits. En otras pala¬ 
bras, se calcula un nuevo mapa de bits donde el bit i 
tiene el valor 1 si el í-ésimo bit de los dos mapas de 
bits es 1, y tiene el valor 0 en caso contrario. En el ejem¬ 
plo de la Figura 12.33, la intersección del mapa de bits 
para sexo = f (01101) y el mapa de bits para nivel-ingre¬ 
sos = L2 (01000) da como resultado el mapa de bits 
01000 . 

Dado que el primer atributo puede tomar dos valores 
y el segundo cinco, se esperaría en media que entre 1 y 
10 registros satisfarían la condición combinada de los 
dos atributos. Si hay más condiciones, la fracción de 
registros que satisfacen todas las condiciones será pro¬ 
bablemente muy pequeña. El sistema puede calcular 
entonces el resultado de la consulta buscando todos los 
bits con valor 1 en el mapa de bits resultado de la inter¬ 
sección, y recuperando los registros correspondientes. 
Si la fracción es grande, la exploración de la relación 
completa seguiría siendo la alternativa menos costosa. 

Otro uso importante de los mapas de bits es contar 
el número de tupias que satisfacen una selección dada. 
Tales consultas son importantes para el análisis de datos. 
Por ejemplo, si deseamos determinar cuántas mujeres 
tienen un nivel de ingresos L2, se calcula la intersec¬ 
ción de los dos mapas de bits y después se cuenta el 
número de bits que son 1 en la intersección. Así se pue¬ 
de obtener el resultado del mapa de bits sin acceder a 
la relación. 

Los índices de mapas de bits son generalmente muy 
pequeños comparados con el tamaño real de la relación. 
Los registros tienen generalmente de decenas a cente¬ 
nas de bytes, mientras que un único bit representa a un 
registro en el mapa de bits. Así, el espacio ocupado por 
un único mapa de bits es usualmente menor que el 1 por 
ciento del espacio ocupado por la relación. Por ejem¬ 
plo, si el tamaño de registro de una relación dada es 100 
bytes, entonces el espacio ocupado por un único mapa 
de bits sería la octava parte del 1 por ciento del espacio 
ocupado por la relación. Si un atributo A de la relación 
puede tomar sólo uno de ocho valores, el índice de 
mapas de bits consistiría en 8 mapas de bits, que juntos 
ocupan sólo el 1 por ciento del tamaño de la relación. 


El borrado de registros crea huecos en la secuencia 
de registros, ya que el desplazamiento de registros (o 
de los números de registro) para rellenar los huecos sería 
excesivamente costoso. Para reconocer los registros 
borrados se puede almacenar un mapa de bits de exis¬ 
tencia en el que el bit i es 0 si el registro i no existe, y 
1 en caso contrario. Se verá la necesidad de la existen¬ 
cia de los mapas de bits en el Apartado 12.9.4.2. La 
inserción de registros no afecta a la secuencia de nume¬ 
ración de otros registros. Por tanto, se puede insertar 
tanto añadiendo registros al final del archivo como reem¬ 
plazando los registros borrados. 

12.9.4.2. Implementación eficiente de las 
operaciones de mapas de bits 

Se puede calcular fácilmente la intersección de dos 
mapas de bits usando un bucle for: la iteración í-ésima 
calcula la conjunción de los í-ésimos bits de los dos 
mapas de bits. Se puede acelerar considerablemente el 
cálculo de la intersección usando las instrucciones de 
bits and soportadas por la mayoría de los conjuntos 
de instrucciones de las computadoras. Una palabra con¬ 
siste generalmente de 32 o 64 bits, dependiendo de la 
arquitectura de la computadora. Una instrucción de bits 
and toma dos palabras como entrada y devuelve una 
palabra en que cada bit es la conjunción lógica de los 
bits en las posiciones correspondientes de las palabras 
de entrada. Lo que es importante observar es que una 
única instrucción de bits and puede calcular la inter¬ 
sección de 32 o 64 bits a la vez. 

Si una relación tuviese un millón de registros, cada 
mapa de bits contendría un millón de bits, o, equivalen¬ 
temente, 128 Kbytes. Sólo se necesitan 31.250 instruc¬ 
ciones para calcular la intersección de dos mapas de bits 
para la relación, asumiendo un tamaño de palabra de 32 
bits. Así, el cálculo de las intersecciones de mapas de 
bits es una operación extremadamente rápida. 

Al igual que la intersección de mapas de bits es útil 
para calcular la conjunción de dos condiciones, la unión 
de mapas de bits es útil para calcular la disyunción de 
dos condiciones. El procedimiento para la unión de 
mapas de bits es exactamente igual que para la inter¬ 
sección, excepto en que se usa la instrucción de bits or 
en lugar de and. 

La operación complemento se puede usar para 
calcular un predicado que incluya la negación de una 
condición, como not (nivel-ingresos = Ll). El comple¬ 
mento de un mapa de bits se genera complementando 
cada bit del mapa de bits (el complemento de 1 es 0 y 
el complemento de 0 es 1). Puede parecer que not(nivel- 
ingresos = L1) se puede implementar simplemente cal¬ 
culando el complemento del mapa de bits para el nivel 
de ingresos Ll. Sin embargo, si se han borrado algunos 
registros, el cálculo del complemento del mapa de bits 
no es suficiente. Los bits que correspondan a esos regis¬ 
tros serían 0 en el mapa de bits original, pero serían 1 
en el complemento, aunque el registro no exista. Tam- 


313 


FUNDAMENTOS DE BASES DE DATOS 


bién aparece un problema similar cuando el valor de un 
atributo es nulo. Por ejemplo, si el valor de nivel-ingre¬ 
sos es nulo, el bit sería 0 en el mapa de bits original para 
el valor Ll y 1 en el complementado. 

Para asegurarse de que los bits correspondientes a 
registros borrados se establezcan a 0 en el resultado, el 
mapa de bits complementado se debe intersectar con el 
mapa de bits de existencia para desactivar los bits de 
los registros borrados. Análogamente, para manejar los 
valores nulos, el mapa de bits complementado también 
se debe intersectar con el complemento del mapa de bits 
para el valor nulo 1 . 

El recuento del número de bits que son 1 en el mapa 
de bits se puede hacer fácilmente con una técnica inte¬ 
ligente. Se puede mantener un array de 256 entradas, 
donde la í-ésima entrada almacene el número de bits 
que son 1 en la representación binaria de i. Se estable¬ 
ce el recuento inicial a 0. Se toma cada byte del mapa 
de bits, se usa para indexar en el array y se añade el 
recuento inicial al recuento total. El número de opera¬ 
ciones de suma sería la octava parte del número de 
tupias, y así el proceso de recuento sería muy eficiente. 
Un gran array (que use 2 16 =65.536 entradas), indexa- 
do por pares de bytes, daría incluso mayores acelera¬ 
ciones pero a un mayor coste de almacenamiento. 

12.9.4.3. Mapas de bits y árboles B + 

Los mapas de bits se pueden combinar con los índices 
normales de árboles B + para las relaciones donde unos 


pocos valores de atributo son extremadamente comu¬ 
nes, y otros valores también aparecen, pero con mucha 
menor frecuencia. En una hoja de un índice de un árbol 
B + , para cada valor se mantendría normalmente una lis¬ 
ta de todos los registros con ese valor para el atributo 
indexado. Cada elemento de la lista sería un identifica- 
dor de registro, consistiendo en al menos 32 bits, y usual¬ 
mente más. Para un valor que aparece en muchos regis¬ 
tros, se almacena un mapa de bits en lugar de una lista 
de registros. 

Supónganse que un valor particular v¡ aparece en la 
dieciseisava parte de los registros de una relación, y 
también que los registros tienen un número de 64 bits 
que los identifica. El mapa de bits necesita sólo 1 bit 
por registro, oN en total. En cambio, la representación 
de lista necesita 64 bits por registro en el que aparezca 
el valor, o 64 * AVI6 = 4 N bits. Así, el mapa de bits es 
preferible para la representación de la lista de registros 
para el valor v¡. En el ejemplo (con un identificador de 
registro de 64 bits), si menos de 1 de cada 64 registros 
tiene un valor particular, es preferible la representación 
de lista de registros para la identificación de registros 
con ese valor, ya que usa menos bits que la representa¬ 
ción con mapas de bits. Si más de 1 de cada 64 regis¬ 
tros tiene un valor particular, la representación de mapas 
de bits es preferible. 

Así, los mapas de bits se pueden usar como un meca¬ 
nismo de almacenamiento comprimido en los nodos 
hoja de los árboles B + , para los valores que aparecen 
muy frecuentemente. 


12.10. RESUMEN 


• Muchas consultas solamente hacen referencia a una 
pequeña proporción de los registros de un archivo. 
Para reducir el gasto adicional en la búsqueda de estos 
registros se pueden construir índices para los archi¬ 
vos almacenados en la base de datos. 

• Los archivos secuenciales indexados son unos de los 
esquemas de índice más antiguos usados en los sis¬ 
temas de bases de datos. Para permitir una rápida recu¬ 
peración de los registros según el orden de la clave 
de búsqueda, los registros se almacenan consecuti¬ 
vamente y los que no siguen el orden se encadenan 
entre sí. Para permitir un acceso aleatorio, se emple¬ 
an estructuras índice. 

• Hay dos tipos de índices que se pueden utilizar: los 
índices densos y los índices dispersos. Los índices 
densos contienen una entrada por cada valor de la 
clave de búsqueda, mientras que los índices disper¬ 


' La gestión de predicados tales como is unknown causaría aún más 
complicaciones, que requerirían en general el uso de un mapa de bits 
extra para determinar los resultados de las operaciones que son des¬ 
conocidos. 


sos contienen entradas sólo para algunos de esos 
valores. 

• Si el orden de una clave de búsqueda se corresponde 
con el orden secuencial del archivo, un índice sobre 
la clave de búsqueda se conoce como índice prima¬ 
rio. Los otros índices son los índices secundarios. Los 
índices secundarios mejoran el rendimiento de las 
consultas que utilizan otras claves de búsqueda apar¬ 
te de la primaria. Sin embargo, éstas implican un gas¬ 
to adicional en la modificación de la base de datos. 

• El inconveniente principal de la organización del 
archivo secuencial indexado es que el rendimiento 
disminuye según crece el archivo. Para superar esta 
deficiencia se puede usar un índice de árbol B + . 

• Un índice de árbol B + tiene la forma de un árbol equi¬ 
librado, en el cual cada camino de la raíz a las hojas 
del árbol tiene la misma longitud. La altura de un árbol 
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B + es proporcional al logaritmo en base N del núme¬ 
ro de registros de la relación, donde cada nodo inter¬ 
no almacena N punteros; el valor de N está usualmente 
entre 50 y 100. Los árboles B + son más cortos que 
otras estructuras de árboles binarios equilibrados como 
los árboles AVL y, por tanto, necesitan menos acce¬ 
sos a disco para localizar los registros. 

• Las búsquedas en un índice de árbol B + son directas 
y eficientes. Sin embargo, la inserción y el borrado 
son algo más complicados pero eficientes. El núme¬ 
ro de operaciones que se necesitan para la inserción 
y borrado en un árbol B + es proporcional al logarit¬ 
mo en base N del número de registros de la relación, 
donde cada nodo interno almacena N punteros. 

• Se pueden utilizar los árboles B + tanto para indexar 
un archivo con registros, como para organizar los 
registros de un archivo. 

• Los índices de árbol B son similares a los índices de 
árbol B + . La mayor ventaja de un árbol B es que el 
árbol B elimina el almacenamiento redundante de los 
valores de la clave de búsqueda. Los inconvenientes 
principales son la complejidad y el reducido grado de 
salida para un tamaño de nodo dado. En la práctica, 
los índices de árbol B + están casi generalmente mejor 
considerados que los índices de árbol B. 

• Las organizaciones de archivos secuenciales necesi¬ 
tan una estructura de índice para localizar los datos. 
Los archivos con organizaciones basadas en asocia¬ 
ción, en cambio, permiten encontrar la dirección de 
un elemento de datos directamente mediante el cál¬ 
culo de una función con el valor de la clave de bús¬ 
queda del registro deseado. Ya que no se sabe en tiem¬ 
po de diseño la manera precisa en la cual los valores 
de la clave de búsqueda se van a almacenar en el archi¬ 


vo, una buena función de asociación a elegir es la que 
distribuya los valores de la clave de búsqueda a los 
cajones de una manera uniforme y aleatoria. 

• La asociación estática utiliza una función de asocia¬ 
ción en la que el conjunto de direcciones de cajones 
está fijado. Estas funciones de asociación no se pue¬ 
den adaptar fácilmente a las bases de datos que ten¬ 
gan un crecimiento significativo con el tiempo. Hay 
varias técnicas de asociación dinámica que permiten 
que la función de asociación cambie. Un ejemplo es 
la asociación extensible, que trata los cambios de 
tamaño de la base datos mediante la división y fusión 
de cajones según crezca o disminuya la base de datos. 

• También se puede utilizar la asociación para crear 
índices secundarios; tales índices se llaman índices 
asociativos. Por motivos de notación se asume que 
las organizaciones de archivos asociativos tienen un 
índice asociativo implícito en la clave de búsqueda 
usada para la asociación. 

• Los índices ordenados con árboles B + y con índices 
asociativos se pueden usar para la selección basada 
en condiciones de igualdad que involucren varios 
atributos. Cuando hay varios atributos en una con¬ 
dición de selección se pueden intersectar los identi- 
ficadores de los registros recuperados con los dife¬ 
rentes índices. 

• Los archivos en retícula proporcionan un medio gene¬ 
ral de indexación con múltiples atributos. 

• Los índices de mapas de bits proporcionan una repre¬ 
sentación muy compacta para la indexación de atri¬ 
butos con muy pocos valores distintos. Las opera¬ 
ciones de intersección son extremadamente rápidas 
en los mapas de bits, haciéndolos ideales para el sopor¬ 
te de consultas con varios atributos. 


TÉRMINOS DE REPASO 


• Acceso con varias claves 

• Lunción de asociación 

• Arbol equilibrado 

• índice con agrupación 

• Archivos en retícula 

• índice sin agrupación 

• Archivo secuencial indexado 

• índice de árbol B 

• Asociación cerrada 

• índice de árbol B + 

• Asociación dinámica 

• índice asociativo 

• Asociación estática 

• índice denso 

• Asociación extensible 

• índice disperso 

• Atasco 

• índice de mapas de bits 

• Cajón 

• índice multinivel 

• Desbordamiento de cajones 

• índice ordenado 

• Espacio adicional 

• índice primario 

• Exploración secuencial 

• índice secundario 
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índices sobre varias claves 
Operaciones de mapas de bits 

- Intersección 

- Unión 

- Complemento 

- Mapa de bits de existencia 
Organización de archivos con árboles B 


Organización de archivos con asociación 

Registro/entrada del índice 

Tiempo de acceso 

Tiempo de borrado 

Tiempo de inserción 

Tipos de acceso 


EJERCICIOS 


12.1. ¿Cuándo es preferible utilizar un índice denso en vez 
de un índice disperso? Razónese la respuesta. 

12.2. Dado que los índices agilizan el procesamiento de 
consultas, ¿por qué no deberían de mantenerse en 
varias claves de búsqueda? Enumérense tantas razo¬ 
nes como sea posible. 

12.3. ¿Cuál es la diferencia entre un índice primario y un 
índice secundario? 

12.4. ¿Es posible en general tener dos índices primarios en 
la misma relación para dos claves de búsqueda dife¬ 
rentes? Razónese la respuesta. 

12.5. Constrúyase un árbol B + con el siguiente conjunto de 
valores de la clave: 

(2, 3,5, 7, 11, 17, 19, 23,29,31) 

Asúmase que el árbol está inicialmente vacío y que 
se añaden los valores en orden ascendente. Constrú- 
yanse árboles B + para los casos en los que el número 
de punteros que caben en un nodo son: 

a. cuatro 

b. seis 

c. ocho 

12.6. Para cada árbol B + del Ejercicio 12.5 muéstrense los 
pasos involucrados en las siguientes consultas: 

a. Encontrar los registros con un valor de la clave de 
búsqueda de 11. 

b. Encontrar los registros con un valor de la clave de 
búsqueda entre 7 y 17, ambos inclusive. 

12.7. Para cada árbol B + del Ejercicio 12.5 muéstrese el 
aspecto del árbol después de cada una de las siguien¬ 
tes operaciones: 

a. Insertar 9. 

b. Insertar 10. 

c. Insertar 8. 

d. Borrar 23. 

e. Borrar 19. 

12.8. Considérese el esquema modificado de redistribución 
para árboles B + descrito en la página 295. ¿Cuál es la 
altura esperada del árbol en función de ni 

12.9. Repítase el Ejercicio 12.5 para un árbol B. 

12.10. Expliqúense las diferencias entre la asociación abier¬ 
ta y la cerrada. Coméntense los beneficios de cada téc¬ 
nica en aplicaciones de bases de datos. 


12.11. ¿Cuáles son las causas del desbordamiento de cajo¬ 
nes en un archivo con una organización asociativa? 
¿Qué se puede hacer para reducir la aparición del des¬ 
bordamiento de cajones? 

12.12. Supóngase que se está usando la asociación extensi- 
ble en un archivo que contiene registros con los 
siguientes valores de la clave de búsqueda: 

2, 3, 5,7, 11, 17, 19, 23,29,31. 

Muéstrese la estructura asociativa extensible para este 
archivo si la función de asociación es h(x) = x mod 8 
y los cajones pueden contener hasta tres registros. 

12.13. Muéstrese cómo cambia la estructura asociativa exten¬ 
sible del Ejercicio 12.12 como resultado de realizar 
los siguientes pasos: 

a. Borrar 12. 

b. Borrar 31. 

c. Insertar 1. 

d. Insertar 15. 

12.14. Dese un pseudocódigo para el borrado de entradas de 
una estructura asociativa extensible, incluyendo deta¬ 
lles del momento y forma de fusionar cajones. No se 
debe considerar la reducción del tamaño de la tabla 
de direcciones de cajones. 

12.15. Sugiérase una forma eficaz de comprobar si la tabla 
de direcciones de cajones en una asociación extensi¬ 
ble se puede reducir en tamaño almacenando un 
recuento extra con la tabla de direcciones de cajones. 
Dense detalles de cómo se debería mantener el recuen¬ 
to cuando se dividen, fusionan o borran los cajones. 

(Nota: la reducción del tamaño de la tabla de direc¬ 
ciones de cajones es una operación costosa y las inser¬ 
ciones subsecuentes pueden causar que la tabla vuel¬ 
va a crecer. Por tanto, es mejor no reducir el tamaño 
tan pronto como se pueda, sino solamente si el núme¬ 
ro de entradas de índice es pequeño en comparación 
con el tamaño de la tabla de direcciones de cajones). 

12.16. ¿Por qué una estructura asociativa no es la mejor elec¬ 
ción para una clave de búsqueda en la que son fre¬ 
cuentes las consultas de rangos? 

12.17. Considérese un archivo en retícula en el cual se desea 
evitar el desbordamiento de cajones por razones de 
rendimiento. En los casos en los que sería necesario 
un cajón de desbordamiento, en su lugar se reorgani¬ 
za el archivo. Preséntese un algoritmo para esta reor¬ 
ganización. 
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12.18. Considérese la relación cuenta mostrada en la Figu¬ 
ra 12.25. 

a. Construyase un índice de mapa de bits sobre los 
atributos nombre-sucursal y saldo , dividiendo sal¬ 
do en cuatro rangos: menores que 250, entre 250 y 
menor que 500, entre 500 y menor que 750, y 750 
o mayor. 

b. Considérese una consulta que solicite todas las 
cuentas de Daimiel con un saldo de 500 o más. 
Descríbanse los pasos para responder a la con¬ 


sulta y muéstrense los mapas de bits finales e 
intermedios construidos para responder la con¬ 
sulta. 

12.19. Muéstrese la forma de calcular mapas de existencia a 
partir de otros mapas de bits. Asegúrese de que la téc¬ 
nica funciona incluso con valores nulos, usando un 
mapa de bits para el valor nulo. 

12.20. ¿Cómo afecta el cifrado de datos a los esquemas de 
índices? En particular, ¿como afectaría a los esque¬ 
mas que intentan almacenar los datos ordenados? 


NOTAS BIBLIOGRÁFICAS 


En Cormen et al. [1990] se pueden encontrar discusio¬ 
nes acerca de las estructuras básicas utilizadas en la 
indexación y asociación. Los índices de árbol B se intro¬ 
dujeron primero en Bayer [1972] y en Bayer y 
McCreight [1972]. Los árboles B + se discuten en Comer 
[1979], Bayer y Unterauer [1977] y Knuth [1973]. Las 
notas bibliográficas del Capítulo 16 proporcionan refe¬ 
rencias a la investigación sobre los accesos concurren¬ 
tes y las actualizaciones en los árboles B + . Gray y Reu- 
ter [1993] proporcionan una buena descripción de los 
resultados en la implementación de árboles B + . 

Se han propuesto varias estructuras alternativas de 
árboles y basadas en árboles. Los tries son unos árbo¬ 
les cuya estructura está basada en los «dígitos» de las 
claves (por ejemplo, el índice de muescas de un dic¬ 
cionario, con una entrada para cada letra). Estos árbo¬ 
les podrían no estar equilibrados en el sentido que lo 
están los árboles B + . Los tries se discuten en Ramesh 
et al. [1989], Orestein [1982], Litwin [1981] y Lredkin 
[1960]. Otros trabajos relacionados son los árboles B 
digitales de Lomet [1981]. 

Knuth [1973] analiza un gran número de técnicas de 
asociación distintas. Existen varias técnicas de asocia¬ 
ción dinámica. Lagin et al. [1979] introduce la asocia¬ 
ción extensible. La asociación lineal se introduce en Lit¬ 


win [1978] y Litwin [1980]; en Larson [1982] se pre¬ 
sentó un análisis del rendimiento de este esquema. Lilis 
[1987] examina la concurrencia con la asociación line¬ 
al. Larson [1988] presenta una variante de la asociación 
lineal. Otro esquema, llamado asociación dinámica se 
propone en Larson [1978]. Una alternativa propuesta en 
Ramakrishna y Larson [1989] permite la recuperación 
en un solo acceso a disco al precio de una gran sobre¬ 
carga en una pequeña fracción de las modificaciones de 
la base de datos. La asociación dividida es una exten¬ 
sión de la asociación para varios atributos, y se trata en 
Rivest [1976], Burkhard [1976] y Burkhard [1979]. 

La estructura de archivo en retícula aparece en Nie- 
vergelt et al [1984] y en Hinrichs [1985]. Los índices de 
mapas de bits y las variantes denominadas índices por 
capas de bits e índices de proyección se describen en 
O’Neil y Quass [1997]. Se introdujeron por primera vez 
en el gestor de archivos Model 204 de IBM sobre la pla¬ 
taforma AS 400. Proporcionan grandes ganancias de 
velocidad en ciertos tipos de consultas y se encuentran 
implementadas actualmente en la mayoría de sistemas 
de bases de datos. La investigación reciente en índices 
de mapas de bits incluye Wu y Buchmann [1998], Chan 
y loannidis [1998], Chan y loannidis [1999] y Johnson 
[1999a]. 
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CAPÍTULO 



PROCESAMIENTO DE CONSULTAS 


E l procesamiento de consultas hace referencia a la serie de actividades implicadas en la 
extracción de datos de una base de datos. Estas actividades incluyen la traducción de 
consultas expresadas en lenguajes de bases de datos de alto nivel en expresiones imple- 
mentadas en el nivel físico del sistema, así como transformaciones de optimización de consul¬ 
tas y la evaluación real de las mismas. 


13.1. VISIÓN GENERAL 


En la Figura 13.1 se ilustran los pasos involucrados en 
el procesamiento de una consulta. Los pasos básicos 
son: 

1. Análisis y traducción 

2. Optimización 

3. Evaluación 

Antes de empezar el procesamiento de una consul¬ 
ta, el sistema debe traducir la consulta a una forma uti- 
lizable. Un lenguaje como SQL es adecuado para el uso 
humano, pero es poco apropiado para una representa¬ 
ción interna en el sistema de la consulta. Así, una repre¬ 
sentación interna más útil está basada en el álgebra rela- 
cional extendida. 

Así, la primera acción que el sistema tiene que 
emprender para procesar una consulta es la traducción 
de la consulta dada a su formato interno. Este proceso 
de traducción es similar al trabajo que realiza el anali¬ 
zador de un compilador. Durante la generación del for¬ 
mato interno de una consulta, el analizador comprueba 
la sintaxis de la consulta del usuario, verifica que los 
nombres de las relaciones que aparecen en la consulta 
sean nombres de relaciones en la base de datos, etcéte¬ 
ra. Luego se construye un árbol para el análisis de la 
consulta, que se transformará en una expresión del álge¬ 
bra relacional. Si la consulta estuviera expresada en tér¬ 
minos de una vista, la fase de traducción también sus¬ 
tituye todos los usos de la vista mediante expresiones 
del álgebra relacional que definen la vista 1 . El análisis 
de lenguajes se describe en la mayoría de los libros sobre 
compiladores (véanse las notas bibliográficas). 


Dada una consulta, hay generalmente varios méto¬ 
dos distintos para obtener la respuesta. Por ejemplo, ya 
se ha visto que en SQL se puede expresar una consulta 
de diferentes maneras. Cada consulta en SQL se puede 
traducir en una expresión del álgebra relacional de varias 
formas. Además de esto, la representación de una con¬ 
sulta en el álgebra relacional especifica de manera par¬ 
cial cómo evaluar la consulta; hay normalmente varias 
maneras de evaluar expresiones del álgebra relacional. 
Como ejemplo, considérese la consulta 

select saldo 
from cuenta 
where saldo < 2500 

Esta consulta se puede traducir en alguna de las siguien¬ 
tes expresiones del álgebra relacional: 

* ° saldo <2500 ( tl S aldo( CUenta )) 

• U saldo (o sald0< 2500 (cuenta)) 

Además, se puede ejecutar cada operación del álge¬ 
bra relacional utilizando alguno de los diferentes algo¬ 
ritmos. Por ejemplo, para implementar la selección ante¬ 
rior se puede examinar cada tupia en cuenta para 
encontrar las tupias cuyo saldo sea menor que 2.500. 
Por otro lado, si se dispone de un índice de árbol B + en 
el atributo saldo, se puede utilizar este índice para loca¬ 
lizar las tupias. 

Para especificar completamente cómo evaluar una 
consulta, no basta con proporcionar la expresión del 
álgebra relacional, además hay que anotar en ellas las 
instrucciones que especifiquen cómo evaluar cada ope- 


1 Para vistas materializadas, la expresión que define la vista ha sido 
ya evaluada y almacenada. Por tanto, se puede usar la relación alma¬ 
cenada en lugar de reemplazar los usos de la vista por la expresión 
que define la vista. Las vistas recursivas se tratan de manera dife¬ 
rente, mediante un procedimiento de búsqueda de punto fijo, según 
se vio en el Apartado 5.2.6. 
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Datos 


Estadísticas 
de los datos 


FIGURA 13.1. Pasos en el procesamiento de una consulta. 

ración. Estas anotaciones podrían ser el algoritmo a usar 
para una operación específica o el índice o índices con¬ 
cretos a utilizar. Las operaciones del álgebra relacional 
anotadas con instrucciones sobre la evaluación reciben 
el nombre de primitivas de evaluación. Una secuen¬ 
cia de operaciones primitivas que se pueden utilizar para 
evaluar una consulta establecen un plan de ejecución 
de la consulta o plan de evaluación de la consulta. 
En la Figura 13.2 se ilustra un plan de evaluación para 
nuestro ejemplo de consulta, en el que se especifica un 
índice concreto (denotado en la figura como «índice 1») 
para la operación selección. El motor de ejecución de 
consultas toma un plan de evaluación, lo ejecuta y 
devuelve su respuesta a la consulta. 

Los diferentes planes de evaluación para una con¬ 
sulta dada pueden tener costes distintos. No se puede 
esperar que los usuarios escriban las consultas de mane¬ 
ra que sugieran el plan de evaluación más eficiente. En 
su lugar, es responsabilidad del sistema construir un 
plan de evaluación de la consulta que minimice el cos¬ 
te de la evaluación de la consulta. El Capítulo 14 des¬ 
cribe en detalle la optimización de consultas. 

Una vez que está elegido el plan de la consulta se 
evalúa la misma con ese plan y se muestra el resultado 
de la consulta. 


La secuencia de pasos que se han descrito para proce¬ 
sar una consulta son representativos; no todas las bases 
de datos los siguen exactamente. Por ejemplo, en lugar 
de utilizar la representación del álgebra relacional, varias 
bases de datos usan una representación anotada del árbol 
de análisis basada en la estructura de la consulta SQL. Sin 
embargo, los conceptos que se describen aquí forman las 
bases del procesamiento de consultas en las bases de datos. 

Para optimizar una consulta, el optimizador de con¬ 
sultas debe conocer el coste de cada operación. Aunque 
el coste exacto es difícil de calcular, dado que depende 
de muchos parámetros como la memoria real disponi¬ 
ble, es posible obtener una estimación aproximada del 
coste de ejecución para cada operación. 

En el Apartado 13.2 se describe cómo medir el cos¬ 
te de una consulta. Desde el Apartado 13.3 hasta el 13.6 
se estudia la evaluación óptima de operaciones indivi¬ 
duales. Varias operaciones se pueden agrupar en un cau¬ 
ce, en el que cada una de las operaciones empieza tra¬ 
bajando sobre sus tupias de entrada del mismo modo 
que si fuesen generadas por otra operación. En el Apar¬ 
tado 13.7 se examina cómo coordinar la ejecución de 
varias operaciones de un plan de evaluación de consul¬ 
tas, en particular cómo usar las operaciones encauzadas 
para evitar escribir resultados intermedios en disco. 


E saldo 


n saldos 2500; utilizar indice 1 


cuenta 


FIGURA 13.2. Plan de ejecución de una consulta. 
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13.2. MEDIDAS DEL COSTE DE UNA CONSULTA 


El coste de la evaluación de una consulta se puede expre¬ 
sar en términos de diferentes recursos, incluyendo los 
accesos a disco, el tiempo de UCP en ejecutar una con¬ 
sulta y, en sistemas de bases de datos distribuidos o para¬ 
lelos, el coste de la comunicación (que se discutirá más 
tarde en los Capítulos 19 y 20). El tiempo de respuesta 
para un plan de evaluación de una consulta (esto es, el 
tiempo de reloj que se necesita para ejecutar el plan), si 
se supone que no hay otra actividad ejecutándose en el 
sistema, podría tener en cuenta todos estos costes y uti¬ 
lizarlos como una buena medida del coste del plan. 

Sin embargo, en grandes sistemas de bases de datos, 
los accesos a disco (que se miden como el número de 
transferencias de bloques de disco) son normalmente el 
coste más importante, ya que los accesos a disco son 
más lentos comparados con las operaciones en memo¬ 
ria. Además, la velocidad de la UCP está aumentando 
mucho más rápidamente que las velocidades de los dis¬ 
cos. Así, lo más probable es que el tiempo empleado en 
operaciones del disco siga influenciando el tiempo total 
de ejecución de una consulta. Por último, las estima¬ 
ciones del tiempo de UCP son más difíciles de hacer, 
comparadas con las estimaciones del coste de los acce¬ 
sos a disco. Por este motivo se considera el coste de los 
accesos a disco una medida razonable del coste del plan 
de evaluación de una consulta. 

Se utilizará simplemente el término número de trans¬ 
ferencias de bloques de disco como una medida del cos¬ 
te real. Para simplificar los cálculos del coste de los 
accesos a disco se asume que todas las transferencias 
de bloques tienen el mismo coste. Esta suposición igno¬ 
ra la varianza que surge de la latencia rotacional (espe¬ 
rando a que el dato deseado gire bajo la cabeza de lec¬ 
tura-escritura) y el tiempo de búsqueda (el tiempo que 
se emplea en mover la cabeza sobre el cilindro o pista 
deseada). Para obtener números más precisos es nece¬ 


sario distinguir entre E/S secuencíal, donde los bloques 
leídos son contiguos en el disco, y la E/S aleatoria, don¬ 
de los bloques no son contiguos, y es necesario pagar 
un coste extra de búsqueda por cada operación E/S. Tam¬ 
bién es necesario distinguir entre las lecturas y escritu¬ 
ras de bloques, dado que se tarda más tiempo en escri¬ 
bir un bloque que leerlo de disco. Una medida más 
precisa sería estimar: 

1. El número de operaciones de búsqueda realiza¬ 
das. 

2. El número de bloques leídos. 

3. El número de bloques escritos. 

y entonces sumar estos números después de multipli¬ 
carlos respectivamente por el tiempo medio de bús¬ 
queda, el tiempo medio de transferencia para la lectura 
de un bloque y el tiempo de transferencia para escribir 
un bloque. Los optimizadores de consultas de la vida 
real también tienen en cuenta los costes de UCP al cal¬ 
cular el coste de una operación. Por simplicidad se igno¬ 
ran estos detalles y se deja como ejercicio para el lec¬ 
tor obtener estimaciones del coste más precisas para las 
diferentes operaciones. 

Las estimaciones de coste que se proporcionan igno¬ 
ran el coste de escribir el resultado final de una opera¬ 
ción en disco. Esto se tiene en cuenta aisladamente cuan¬ 
do sea preciso. Los costes de todos los algoritmos que 
se consideran aquí dependen del tamaño de la memo¬ 
ria intermedia en la memoria principal. En el mejor caso, 
todos los datos se pueden leer en las memorias inter¬ 
medias y no es necesario acceder a disco de nuevo. En 
el peor caso se asume que la memoria intermedia pue¬ 
de contener sólo unos pocos bloques de datos, aproxi¬ 
madamente un bloque por relación. Al presentar las esti¬ 
maciones de coste se asume generalmente el peor caso. 


13.3. OPERACIÓN SELECCIÓN 


En el procesamiento de consultas, el explorador de 
archivo es el operador de nivel más bajo para acceder 
a los datos. Los exploradores de archivo son algoritmos 
de búsqueda que localizan y recuperan los registros que 
cumplen una condición de selección. En los sistemas 
relaciónales, el explorador de archivo permite leer una 
relación completa en esos casos donde la relación se 
almacena en un único archivo dedicado. 

13.3.1. Algoritmos básicos 

Considérese una operación selección en una relación 
cuyas tupias se almacenan juntas en un archivo. A con¬ 


tinuación se muestran dos algoritmos exploradores que 
implementan la operación selección: 

• Al (búsqueda lineal). En una búsqueda lineal se 
explora cada bloque del archivo y se comprueban 
todos los registros para ver si satisfacen la condi¬ 
ción de selección. Para una selección sobre un atri¬ 
buto clave, el sistema puede terminar la explora¬ 
ción si se encuentra el registro requerido sin 
necesidad de examinar los otros registros de la rela¬ 
ción. 

El coste de la búsqueda lineal, en términos de 
operaciones E/S es b,., donde b r denota el número 


321 







FUNDAMENTOS DE BASES DE DATOS 


de bloques del archivo. Las selecciones sobre atri¬ 
butos clave tienen un coste medio de b r l 2, pero 
aún tiene el coste en el peor caso de b r 

Aunque podría ser más lento que otros algorit¬ 
mos para la implementación de la selección, el 
algoritmo de búsqueda lineal se puede aplicar a 
cualquier archivo, sin importar la ordenación del 
archivo, la presencia de índices o la naturaleza de 
la operación selección. Los otros algoritmos que 
se estudiarán no son aplicables en todos los casos, 
pero cuando lo son, son más rápidos que la bús¬ 
queda lineal. 

• A2 (búsqueda binaria). Si el archivo está orde¬ 
nado según un atributo y la condición de la selec¬ 
ción es una comparación de igualdad en ese atri¬ 
buto, se puede utilizar una búsqueda binaria para 
localizar los registros que satisfacen la selección. 
El sistema realiza la búsqueda binaria de los blo¬ 
ques del archivo. 

El número de bloques que deben ser exami¬ 
nados para encontrar los registros requeridos es 
flog 2 (b,) 1, donde b r denota el número de bloques 
del archivo. Si la selección no es sobre un atribu¬ 
to clave, más de un bloque puede contener los 
registros requeridos, y el coste de la lectura de los 
bloques extra se debe añadir a la estimación del 
coste. Se puede estimar este número mediante la 
estimación del tamaño del resultado de la selec¬ 
ción (que se explica en el Apartado 14.2) y divi¬ 
diéndolo entre el número de registros que se alma¬ 
cenan por bloque de la relación. 

13.3.2. Selecciones con índices 

Las estructuras índice se denominan caminos de acce¬ 
so, ya que proporcionan un camino a través del cual se 
pueden localizar y acceder a los datos. En el Capítulo 
12 se señaló la eficiencia de leer los registros del archi¬ 
vo en un orden próximo al orden físico. Recuérdese que 
un índice primario es un índice que permite leer los 
registros de un archivo en un orden que se corresponde 
con la ordenación física del archivo. Un índice que no 
es primario se llama índice secundario. 

Los algoritmos de búsqueda que utilizan un índice 
reciben el nombre de exploraciones del índice. Los índi¬ 
ces ordenados, como los árboles B + , también permiten 
acceder a las tupias según cierto orden que es útil para 
la implementación de las consultas de rangos. Aunque 
los índices pueden proporcionar un acceso rápido, direc¬ 
to y ordenado, su utilización implica un gasto adicional 
en los accesos a los bloques que contienen el índice. Uti¬ 
lizaremos el predicado de selección como guía en la selec¬ 
ción del índice a usar en el procesamiento de la consul¬ 
ta. Los algoritmos de búsqueda que usan un índice son: 

• A3 (índice primario, igualdad basada en la cla¬ 
ve). Para una condición de igualdad en un atribu¬ 
to clave con un índice primario se puede utilizar 


el índice para recuperar el único registro que satis¬ 
face la correspondiente condición de igualdad. 

Si se usa un árbol B + , el coste de la operación 
en términos de operaciones E/S es igual a la altu¬ 
ra del árbol más una operación E/S para recuperar 
el registro. 

• A4 (índice primario, igualdad basada en un atri¬ 
buto no clave). Se pueden recuperar varios regis¬ 
tros mediante el uso de un índice primario cuando 
la condición de selección especifica una compara¬ 
ción de igualdad en un atributo A que no sea cla¬ 
ve. La única diferencia del caso anterior es que 
puede ser necesario recuperar varios registros. Sin 
embargo, estos registros estarían almacenados con¬ 
secutivamente en el archivo, ya que el archivo se 
ordena según la clave de búsqueda. 

• A5 (índice secundario, igualdad). Las seleccio¬ 
nes con una condición de igualdad pueden utilizar 
un índice secundario. Esta estrategia puede recu¬ 
perar un único registro si la condición de igualdad 
es sobre una clave; puede que se recuperen varios 
registros si el campo índice no es clave. 

En el primer caso sólo se obtiene un registro, y 
el coste es igual a la altura del árbol más una ope¬ 
ración E/S para recuperar el registro. En el segun¬ 
do caso, cada registro puede residir en un bloque 
diferente, que puede resultar en una operación E/S 
por cada registro recuperado. El coste podría lle¬ 
gar a ser incluso peor que el de la búsqueda line¬ 
al si se obtiene un gran número de registros. 

Supongamos que se utiliza la misma informa¬ 
ción estadística de la relación cuenta utilizada en 
el ejemplo anterior. Supóngase también la exis¬ 
tencia de los siguientes índices en la relación cuen¬ 
ta. 

• Un índice árbol B + primario para el atributo nom¬ 
bre-sucursal 

• Un índice árbol B + secundario para el atributo 
saldo + 

Como se mencionó anteriormente, se asume la 
simplificación de que los valores se distribuyen de 
manera uniforme. 

Si se usan organizaciones de archivos de árboles B + 
para almacenar relaciones, los registros se puede tras¬ 
ladar entre los bloques cuando los nodos hoja se divi¬ 
den o combinan y cuando se redistribuyen. Si los índi¬ 
ces secundarios almacenan punteros a la ubicación física 
de los registros, los punteros tendrán que actualizarse 
cuando se trasladen los registros. En algunos sistemas, 
como Non-Stop SQL System de Compaq, los índices 
secundarios almacenan el valor de la clave en la orga¬ 
nización de archivos de árboles B + . El acceso a un regis¬ 
tro mediante un índice secundario es incluso más caro, 
dado que se debe realizar la búsqueda en el árbol B + 
usado en la organización de archivos. La fórmula del 
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coste descrita para índices secundarios tendrá que ser 
modificada adecuadamente si se usan tales índices. 

13.3.3. Selecciones con condiciones 
de comparación 

Considérese una selección de la forma o A £ v (/). Se pue¬ 
den implementar utilizando búsqueda lineal o binaria, 
o con índices de alguna de las siguientes maneras: 

• A6 (índice primario, comparación). Se puede uti¬ 
lizar un índice ordenado primario (por ejemplo, un 
índice primario de árbol B + ) cuando la condición de 
selección es una comparación. Para condiciones con 
comparaciones de la forma A > y o A > y se puede 
usar el índice primario para guiar la recuperación 
de las tupias de la manera siguiente. Para el caso de 
A > v se busca el valor de v en el índice para encon¬ 
trar la primera tupia del archivo que tenga un valor 
de A = v. Un explorador de archivo comenzando en 
esa tupia y hasta el final del archivo devuelve todas 
las tupias que satisfacen la condición. Para A > v, el 
explorador de archivo comienza con la primera tupia 
tal que A > v. 

Para comparaciones de la forma A < v o A < v 
no es necesario buscar en el índice. Para el caso 
de A < v, se utiliza un simple explorador de archi¬ 
vo partiendo del inicio del archivo y continuando 
hasta (pero sin incluirlo) la primera tupia con el 
atributo A = v. El caso A < v es similar, excepto 
que el explorador continúa hasta (pero sin incluir) 
la primera tupia con el atributo A > v. Para ambos 
casos el índice no es de utilidad alguna. 

• A7 (índice secundario, comparación). Se puede 
utilizar un índice secundario ordenado para guiar 
la recuperación bajo condiciones de comparación 
que contengan <, < , > o >. Los bloques del índi¬ 
ce del nivel más bajo se exploran o bien desde el 
valor más pequeño hasta v (para < y <) o bien des¬ 
de v hasta el valor más grande (para > y >). 

El índice secundario proporciona punteros a los 
registros, pero para obtener los registros reales hay 
que extraer los registros usando los punteros. Este 
paso puede requerir una operación E/S por cada 
registro extraído, dado que los registros consecu¬ 
tivos pueden estar en diferentes bloques de disco. 
Si el número de registros extraídos es grande, el 
uso del índice secundario puede ser incluso más 
caro que la búsqueda lineal. Por tanto, el índice 
secundario sólo se debería usar si se seleccionan 
muy pocos registros. 

13.3.4. Implementación de selecciones 
complejas 

Hasta ahora sólo se han considerado condiciones de 
selección simples de la forma A op B , donde op es una 


operación igualdad o de comparación. Se revisarán a 
continuación predicados de selección más complejos. 

• Conjunción: Una selección conjuntiva es una 
selección de la forma 

0 ’g,K6 2 a ... a 0 „ ( r ) 

• Disyunción: Una selección disyuntiva es una selec¬ 
ción de la forma 

°0 1 v0 2 v ... V0„ ( r ) 

Una condición disyuntiva se cumple mediante la 
unión de todos los registros que cumplen las con¬ 
diciones individuales 6¡. 

• Negación: El resultado de una selección o^ g (r) es 
el conjunto de tupias de r para las que la condición 
d se evalúa a falso. En ausencia de nulos, este con¬ 
junto es simplemente el conjunto de tupias que no 
están en o g (r). 

Se puede implementar una operación selección con 
una conjunción o una disyunción de condiciones sen¬ 
cillas utilizando alguno de los siguientes algoritmos: 

• A8 (selección conjuntiva utilizando un índice). 

Primero hay que determinar si para un atributo hay 
disponible algún camino de acceso en alguna de 
las condiciones simples. Si lo hay, cualquiera de 
los algoritmos de selección A2 hasta A7 puede 
recuperar los registros que cumplan esa condición. 
Se completa la operación mediante la comproba¬ 
ción en la memoria intermedia de que cada regis¬ 
tro recuperado cumpla o no el resto de condicio¬ 
nes simples. 

Para reducir el coste, se elige un B¡ y uno de los 
algoritmos entre Al y A7 para los que la combi¬ 
nación de resultados es el menor coste de o g . ( r ). 
El coste del algoritmo A8 está determinado por el 
coste del algoritmo elegido. 

• A9 (selección conjuntiva utilizando un índice 
compuesto). Se podría disponer de un índice com¬ 
puesto (es decir, un índice sobre varios atributos) 
apropiado para algunas selecciones conjuntivas. 
Si la selección especifica una condición de igual¬ 
dad en dos o más atributos y existe un índice com¬ 
puesto en estos campos con atributos combinados, 
entonces se podría buscar en el índice directamente. 
El tipo de índice determina cuál de los algoritmos 
A3, A4 o A5 se utilizará. 

• A10 (selección conjuntiva mediante la inter¬ 
sección de identificadores). Otra alternativa para 
implementar la operación selección conjuntiva 
implica la utilización de punteros a registros o iden¬ 
tificadores de registros. Este algoritmo necesita 
índices con punteros a registros en los campos 
involucrados por cada condición individual. De 
este modo se explora cada índice en busca de pun¬ 
teros cuyas tupias cumplan alguna condición indi- 
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vidual. La intersección de todos los punteros recu¬ 
perados forma el conjunto de punteros a tupias que 
satisfacen la condición conjuntiva. Luego se usa 
el conjunto de punteros para recuperar los regis¬ 
tros reales. Si no hubiera índices disponibles para 
algunas condiciones concretas entonces habría que 
comprobar el resto de condiciones de los registros 
recuperados. 

El coste del algoritmo A10 es la suma de los 
costes de las cada una de las exploraciones del índi¬ 
ce más el coste de recuperar los registros en la 
intersección de las listas recuperadas de punteros. 
Este coste se puede reducir ordenando la lista de 
punteros y recuperando registros en orden. Por tan¬ 
to, (1) todos los punteros a los registros de un blo¬ 
que van juntos, y así todos los registros seleccio¬ 
nados en el bloque se pueden recuperar usando una 
única operación E/S, y (2) los bloques se leen orde¬ 
nados, minimizando el movimiento del brazo del 
disco. El apartado 13.4 describe algunos algorit¬ 
mos de ordenación. 


• All (selección disyuntiva mediante la unión de 
identificadores). Si se disponen de caminos de acce¬ 
so en todas las condiciones de la selección disyun¬ 
tiva, se explora cada índice en busca de punteros 
cuyas tupias cumplan una condición individual. La 
unión de todos los punteros recuperados propor¬ 
ciona el conjunto de punteros a todas las tupias que 
cumplen la condición disyuntiva. Luego se utilizan 
estos punteros para recuperar los registros reales. 

Sin embargo, aunque solamente una de las con¬ 
diciones no tenga un camino de acceso, se tiene 
que realizar una búsqueda lineal en la relación para 
encontrar todas las tupias que cumplan la condi¬ 
ción. Por tanto, aunque sólo exista una de estas 
condiciones en la disyunción, el método de acce¬ 
so más eficiente es una exploración lineal, com¬ 
probando durante la búsqueda la condición dis¬ 
yuntiva en cada tupia. 

La implementación de selecciones con condiciones 
negativas se deja como ejercicio (Ejercicio 13.10). 


13.4. ORDENACIÓN 


La ordenación de los datos juega un papel importante en 
los sistemas de bases de datos por dos razones. Prime¬ 
ro, las consultas SQL pueden solicitar que los resulta¬ 
dos sean ordenados. Segundo, e igualmente importante 
para el procesamiento de consultas, varias de las opera¬ 
ciones relaciónales, como las reuniones, se pueden imple- 
mentar eficientemente si las relaciones de entrada están 
ordenadas. Por este motivo se revisa la ordenación antes 
que la operación reunión en el Apartado 13.5. 

Se puede conseguir la ordenación mediante la cons¬ 
trucción de un índice en la clave de ordenación y utili¬ 
zando luego ese índice para leer la relación de manera 
ordenada. No obstante, este proceso ordena la relación 
sólo lógicamente a través de un índice, en lugar de físi¬ 
camente. Por tanto, la lectura de las tupias de manera orde¬ 
nada podría imphcar acceder al disco para cada tupia. Por 
esta razón sería deseable ordenar las tupias físicamente. 

El problema de la ordenación se ha estudiado 
ampliamente para los casos en que la relación cabe com¬ 
pletamente en memoria principal, y para el caso en el 
que la relación es mayor que la memoria. En el primer 
caso se utilizan técnicas de ordenación clásicas como 
la ordenación rápida ( quicksort ). Aquí se discute cómo 
tratar el segundo caso. 

La ordenación de relaciones que no caben en memo¬ 
ria se llama ordenación externa. La técnica más utili¬ 
zada para la ordenación externa es normalmente el algo¬ 
ritmo de ordenación-mezcla externa. A continuación 
se describe el algoritmo de ordenación-mezcla externa. 
Sea M el número de marcos de página en la memoria 
intermedia de la memoria principal (el número de blo¬ 


ques de disco cuyos contenidos se pueden alojar en la 
memoria intermedia de la memoria principal). 

1. En la primera etapa, se crean varias secuencias 
ordenadas. 

i = 0; 

repeat 

leer M bloques o bien de la relación o 
bien del resto de la relación según el 
que tenga menor número de bloques; 
ordenar la parte en memoria de la 
relación; 

escribir los datos ordenados al archivo 
de secuencias S¡\ 
i = i + 1; 

until el final de la relación 

2. En la segunda etapa, las secuencias se mezclan. 
Supóngase que, por ahora, el número total de 
secuencias N es menor que M, así que se puede 
asignar un marco de página para cada secuencia 
y reservar espacio para guardar una página con 
el resultado. La etapa de mezcla se lleva a cabo 
de la siguiente manera: 

leer un bloque de cada uno de los N archivos 
S¡ y guardarlos en una página de la 
memoria intermedia en memoria; 

repeat 

elegir la primera tupia (según el orden) 
de entre todas las páginas de la 
memoria intermedia; 
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escribir la tupia y suprimirla de la 
página de la memoria intermedia; 
if la página de la memoria intermedia de 
alguna secuencia S¡ está vacía and 
not fin-de-archivo(S,) then leer el 
siguiente bloque de S¡ y guardarlo en 
la página de la memoria intermedia; 
until todas las páginas de la memoria 
intermedia estén vacías 

El resultado de la etapa de mezcla es la relación 
ya ordenada. El archivo de salida se almacena en una 
memoria intermedia para reducir el número de ope¬ 
raciones de escritura en el disco. La operación ante¬ 
rior de mezcla es una generalización de la mezcla de 
dos vías utilizado por el algoritmo normal de orde¬ 
nación-mezcla en memoria; éste mezcla N secuen¬ 
cias, por eso se llama mezcla de n vías. 

En general, si la relación es mucho más grande 
que la memoria, se podrían generar M o más secuen¬ 
cias en la primera etapa y no sería posible asignar un 
marco de página para cada secuencia durante la eta¬ 
pa de mezcla. En este caso, se realiza la operación de 
mezcla en varios ciclos. Como hay suficiente memo¬ 
ria para M — 1 páginas de la memoria intermedia de 
entrada, cada mezcla puede tomar M - 1 secuencias 
como entrada. 

El ciclo inicial se realiza como sigue. Se mezclan 
las M — 1 secuencias primeras (según se describió 
anteriormente) para obtener un única secuencia en el 


siguiente ciclo. Luego se mezclan de manera similar 
las siguientes M - 1 secuencias, continuando así has¬ 
ta que todas las secuencias iniciales se hayan proce¬ 
sado. En este punto, el número de secuencias se ha 
reducido por un factor de M - 1. Si el número redu¬ 
cido de secuencias es todavía mayor o igual que M, 
se realiza otro ciclo con las secuencias creadas en el 
primer ciclo como entrada. Cada ciclo reduce el 
número de secuencias por un factor de M - 1. Se repi¬ 
ten estos ciclos tantas veces como sea necesario, has¬ 
ta que el número de secuencias sea menor que M; 
momento en el que un último ciclo genera el resul¬ 
tado ordenado. 

En la Figura 13.3 se ilustran los pasos de la orde¬ 
nación-mezcla externa en una relación ficticia. Por 
motivos didácticos supóngase que solamente cabe 
una tupia en cada bloque (f r = 1) y que la memoria 
puede contener como mucho tres marcos de página. 
Durante la etapa de mezcla se utilizan dos marcos de 
página como entrada y uno para la salida. 

Calculemos cuántas transferencias de bloques se 
necesitan para la ordenación-mezcla externa. Sea b r 
el número de bloques que contienen registros de la 
relación r. En la primera etapa, cada bloque de la rela¬ 
ción se lee y se copia de nuevo, dando un total de 2 b r 
accesos a disco. El número inicial de secuencias es 
[b r l M~ |. Puesto que el número de secuencias decre¬ 
ce en un factor de M - 1 en cada ciclo de la mezcla, 
el número total de ciclos requeridos viene dado por 
la expresión flog M _ , ( b r / M)~\ . Cada uno de estos 



Relación 

inicial 



Creación 1. er ciclo de 

de secuencias la mezcla 


2° ciclo de 
la mezcla 


FIGURA 13.3. Ordenación externa utilizando ordenación-mezcla. 
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ciclos leen todos los bloques de la relación una vez y 
los copian al momento, con dos excepciones. Prime¬ 
ro, el ciclo final puede producir la ordenación como 
resultado sin escribir el resultado en disco. Segundo, 
podría haber secuencias que ni lean ni copien duran¬ 
te un ciclo; por ejemplo, si hay M secuencias para 
mezclar en un ciclo, se leen M— 1 y se mezclan, para 
dejar la ejecución restante sin ser accedida durante 
este ciclo. Si se ignora el número (relativamente 
pequeño) de almacenamientos debido al último efec¬ 


to, el número total de accesos a disco para la ordena¬ 
ción externa es 

b, (2 Rog u.^b'/M)-] +1) 

Aplicando esta ecuación al ejemplo de la Figura 
13.3 se obtiene un total de 12 * (4 + 1) = 60 bloques 
transferidos, como se puede comprobar en la figura. 
Obsérvese que este valor no incluye el coste de escri¬ 
bir el resultado final. 


13.5. OPERACIÓN REUNIÓN 


En este apartado se estudian varios algoritmos para cal¬ 
cular la reunión de relaciones y para analizar sus cos¬ 
tes asociados. 

Se utiliza la palabra equirreunión para hacer refe¬ 
rencia a las reuniones de la forma r s, donde A y 

B son atributos o conjuntos de atributos de las relacio¬ 
nes rys respectivamente. 

Utilizaremos como ejemplo la expresión 

impositor IX cliente 

Se asume la siguiente información de catálogo acerca 
de las dos relaciones: 

• Número de registros de cliente: n cliente = 10.000. 

• Número de bloques de cliente: b diente = 400. 

• Número de registros de impositor. n- ositor = 

= 5.000. 

• Número de bloques de impositor. b¡ ositor = 100. 

13.5.1. Reunión en bucle anidado 

En la Figura 13.4 se muestra un algoritmo sencillo para 
calcular la reunión zeta, r M e s, de dos relaciones rys. 
Este algoritmo se llama de reunión en bucle anidado, 
ya que básicamente consiste en un par de bucles for ani¬ 
dados. La relación r se denomina la relación externa 
y ^ la relación interna de la reunión, puesto que el bucle 
de r incluye al bucle de 5. El algoritmo utiliza la nota¬ 
ción t r ■ t s , donde t r y t s son tupias; t r • t s denota a la tupia 
construida mediante la concatenación de los valores de 
los atributos de las tupias t r y t s . 

for each tupia t r in r do begin 
for each tupia t s in s do begin 

comprobar que el par (t r , t s ) satisface la condición 9 de 
la reunión 

si la cumple, añadir t r ■ t s al resultado. 

end 

end 

FIGURA 13.4. Reunión en bucle anidado. 


Al igual que el algoritmo de búsqueda lineal en archi¬ 
vos de la selección, el algoritmo de reunión en bucle 
anidado no necesita índices y se puede utilizar sin impor¬ 
tar la condición de la reunión. La manera de extender 
el algoritmo para calcular la reunión natural es directa, 
puesto que la reunión natural se puede expresar como 
una reunión zeta seguida de la eliminación de los atri¬ 
butos repetidos mediante una proyección. El único cam¬ 
bio que se necesita es un paso adicional para borrar los 
atributos repetidos de la tupia t r ■ t s antes de añadirla al 
resultado. 

El algoritmo de reunión en bucle anidado es costo¬ 
so, ya que examina cada pareja de tupias en las dos rela¬ 
ciones. Considérese el coste del algoritmo de reunión 
en bucle anidado. El número de pares de tupias a con¬ 
siderar es n r * n.. Además, para cada registro en r, se 
tiene que realizar una exploración completa de 5. En el 
peor de los casos, la memoria intermedia solamente pue¬ 
de contener un bloque de cada relación, necesitándose 
un total de n r * b s + b r accesos de bloques. En el mejor 
de los casos hay suficiente espacio para que las dos rela¬ 
ciones quepan en memoria, así que cada bloque se ten¬ 
drá que leer solamente una vez; en consecuencia, sólo 
se necesitará acceder a b r + b s bloques. 

Si una de las relaciones cabe en memoria por com¬ 
pleto, es útil usar esa relación como la relación más 
interna. De este modo se agiliza el procesamiento de la 
consulta significativamente, puesto que solamente será 
necesario leer una vez la relación del bucle más inter¬ 
no. Por lo tanto, si s es lo suficientemente pequeña para 
caber en la memoria principal, esta estrategia necesita 
solamente un total de b r + b s accesos, el mismo coste 
que en el caso de las dos relaciones que caben en me¬ 
moria. 

Considérese ahora el caso de la reunión natural de 
impositor y cliente. Supóngase que, por el momento, 
no hay ningún índice en cualquiera de las relaciones 
y que no se desea crear un índice. Se pueden utilizar 
los bucles anidados para calcular la reunión; supón¬ 
gase que impositor es la relación externa y que clien¬ 
te es la relación interna de la reunión. Se tendrán que 
examinar 5.000 * 10.000 = 50 • 10 6 pares de tupias. 
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En el peor de los casos el número de accesos será de 
5.000 * 400 + 100 = 2.000.100 bloques. En la mejor 
de las situaciones, sin embargo, se tienen que leer 
ambas relaciones solamente una vez y realizar el cál¬ 
culo. Este cálculo necesita a lo sumo 100 + 400 = 500 
accesos a bloques, una mejora significativa sobre 
la situación en el peor de los casos. Si se hubiera uti¬ 
lizado cliente como la relación del bucle externo e 
impositor para el bucle interno, el coste en el peor de 
los casos de la última estrategia habría sido menor: 
10.000 * 100 + 400 = 1.000.400. 

13.5.2. Reunión en bucle anidado por bloques 

Si la memoria intermedia es demasiado pequeña para 
contener las dos relaciones por completo en memoria, 
todavía se puede lograr un mayor ahorro en los accesos 
a los bloques si se procesan las relaciones por bloques 
en lugar de por tupias. El procedimiento de la Figura 
13.5 muestra una variante de la reunión en bucle ani¬ 
dado, donde se empareja cada bloque de la relación inter¬ 
na con cada bloque de la relación externa. En cada par 
de bloques se empareja cada tupia de un bloque con 
cada tupia del otro bloque para generar todos los pares 
de tupias. Al igual que antes, se añaden al resultado todas 
las parejas de tupias que satisfacen la condición de la 
reunión. 

La diferencia principal en coste entre la reunión en 
bucle anidado por bloques y la reunión en bucle anida¬ 
do básica es que, en el peor de los casos, cada bloque 
de la relación interna 5 se lee solamente una vez por 
cada bloque de la relación externa, en lugar de una vez 
por cada tupia de la relación externa. De este modo, en 
el peor de los casos, habrá un total de b,. * b s + b r acce¬ 
sos a bloques, donde b r y b s denotan respectivamente el 
número de bloques que contienen registros dery s. Evi¬ 
dentemente, será más eficiente utilizar la relación más 
pequeña como la relación externa. En el mejor de los 
casos habrá que acceder a b r + h s bloques. 

Volvamos al ejemplo de calcular impositor tx clien¬ 
te pero utilizando ahora el algoritmo de reunión en 
bucle anidado por bloques. En el peor de los casos 
hay que leer una vez cada bloque de cliente por cada 
bloque de impositor. Así, en el peor caso, es necesa¬ 
rio acceder un total de 100 * 400 + 100 = 40.100 blo¬ 
ques. Este coste es una mejora importante frente a los 


5.000 * 400 + 100 = 2.000.100 accesos a bloques 
necesarios en el peor de los casos para la reunión en 
bucle anidado básica. Sin embargo el número de acce¬ 
sos a bloques en el mejor caso sigue siendo el mismo, 
es decir, 100 + 400 = 500. 

El rendimiento de los procedimientos de bucle anida¬ 
do y bucle anidado por bloques se puede mejorar aún más: 

• Si los atributos de la reunión en una reunión natu¬ 
ral o una equirreunión forman una clave de la rela¬ 
ción interna, entonces el bucle interno puede fina¬ 
lizar tan pronto como se encuentre la primera 
correspondencia. 

• En el algoritmo en bucle anidado por bloques, en 
lugar de utilizar bloques de disco como la unidad 
de bloqueo de la relación externa, se puede utili¬ 
zar el mayor tamaño que quepa en memoria, mien¬ 
tras quede suficiente espacio para las memorias 
intermedias de la relación interna y la salida. En 
otras palabras, si la memoria tiene M bloques, se 
leen M- 2 bloques de la relación externa de una vez, 
y cuando se lee cada bloque de la relación interna 
se reúne con los M-2 bloques de la relación exter¬ 
na. Este cambio reduce el número de exploracio¬ 
nes de la relación interna de b r a \b,J(M- 2)], don¬ 
de b r es el número de bloques de la relación 
externa. El coste total es [ bJ(M- 2)] * b s + b r . 

• Se puede explorar el bucle intemo alternativamente 
hacia adelante y hacia atrás. Este método de bús¬ 
queda ordena las peticiones de bloques de disco 
de tal manera que los datos restantes en la memo¬ 
ria intermedia de la búsqueda anterior se reutili¬ 
zan, reduciendo de este modo el número de acce¬ 
sos a disco necesarios. 

• Si se dispone de un índice en un atributo de la reu¬ 
nión del bucle interno se pueden sustituir las bús¬ 
quedas en archivos por búsquedas más eficientes 
en el índice. Esta optimización se describe en el 
Apartado 13.5.3. 


13.5.3. Reunión en bucle anidado indexada 

En una reunión en bucle anidado (Figura 13.4), si se 
dispone de un índice sobre el atributo de la reunión del 


for each bloque B r of rdo begin 
for each bloque B s of s do begin 
for each tupia t r in B r do begin 
for each tupia t s in B s do begin 

comprobar que el par ( t r , t s ) satisface la condición de la reunión 
si la cumple, añadir t r ■ t s al resultado. 

end 

end 

end 

end 

FIGURA 13.5. Reunión en bucle anidado por bloques. 
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bucle interno, se pueden sustituir las exploraciones de 
archivo por búsquedas en el índice. Para cada tupia t r 
de la relación externa r, se utiliza el índice para buscar 
tupias en s que cumplan la condición de reunión con la 
tupia t r . 

Este método de reunión se llama reunión en bucle 
anidado indexada; se puede utilizar cuando existen 
índices, así como cuando se crean índices temporales 
con el único propósito de evaluar la reunión. 

La búsqueda de tupias en s que cumplan las condi¬ 
ciones de la reunión con una tupia dada t r es esencial¬ 
mente una selección en 5 . Por ejemplo, considérese 
impositor x cliente. Supóngase que se tiene una tupia 
de impositor con nombre-cliente «Juan». Entonces, las 
tupias relevantes en 5 son aquellas que satisfacen la 
selección «nombre-cliente = Juan». 

El coste de la reunión en bucle anidado indexada se 
puede calcular como se indica a continuación. Para cada 
tupia en la relación externa r se realiza una búsqueda 
en el índice para s recuperando las tupias apropiadas. 
En el peor de los casos sólo hay espacio en la memoria 
intermedia para una página de r y una página del índi¬ 
ce. Por tanto, son necesarios b r accesos a disco para leer 
la relación r, donde b r denota el número de bloques que 


contienen registros de r. Para cada tupia de r, se reali¬ 
za una búsqueda en el índice para 5 . Luego el coste de 
la reunión se puede calcular como b r + n r ■ c, donde n r 
es el número de registros de la relación r y c es el cos¬ 
te de una única selección en s utilizando la condición 
de la reunión. Ya se vio cómo estimar el coste del algo¬ 
ritmo de una única selección (posiblemente utilizando 
índices) cuyo cálculo proporciona el valor de c. 

La fórmula del coste indica que, si hay índices dis¬ 
ponibles en ambas relaciones r y s, normalmente es más 
eficiente usar como relación más externa aquella que 
tenga menos tupias. 

Por ejemplo, considérese una reunión en bucle ani¬ 
dado indexada de impositor IX cliente, con impositor 
como la relación externa. Supóngase también que 
cliente tiene un índice de árbol B + primario en el atri¬ 
buto de la reunión nombre-cliente, que contiene 20 
entradas en promedio por cada nodo del índice. Dado 
que cliente tiene 10.000 tupias, la altura del árbol es 
4, y será necesario un acceso más para encontrar el 
dato real. Como n impositor es 5.000, el coste total es 100 
+ 5.000 * 5 = 25.100 accesos a disco. Este coste es 
menor que los 40.100 accesos necesarios para una reu¬ 
nión en bucle anidado por bloques. 


pr.= dirección de la primera tupia de r; 
ps:= dirección de la primera tupia de s; 
while (ps* nuil and pr* nuil) do 
begin 

f s := tupia a la que apunta ps; 

S s := (D; 

hacer que ps apunte a la siguiente tupia de s; 
hecho;= falso; 

while (not hecho and ps * nuil) do 
begin 

t s ':= tupia a la que apunta ps; 

¡f (tj [AtribsReunión] = t s [AtribsReunión]) 
then begin 

S s := S s U (tj); 

hacer que ps apunte a la siguiente tupia de s; 

end 

else hecho\= cierto; 

end 

f r := tupia a la que apunta pr; 

while (pr* nuil and t r [Atr¡bsReunión] < t s [Atr¡bsReun¡ón]) do 

begin 

hacer que prapunte a la siguiente tupia de r; 
t¿= tupia a la que apunta pr; 

end 

while (pr* nuil and t r [Atr¡bsReun¡ón] = t s [Atr¡bsReunión ]) do 

begin 

for each f s ¡n S s do 

begin 

añadir f s M f r al resultado; 

end 

hacer que prapunte a la siguiente tupia de r; 
f r := tupia a la que apunta pr; 

end 


end. 

FIGURA 13.6. Reunión por mezcla. 
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13.5.4. Reunión por mezcla 

El algoritmo de reunión por mezcla (también llamado 
algoritmo de reunión por ordenación-mezcla) se pue¬ 
de utilizar para calcular reuniones naturales y equi- 
rreuniones. Sean r(R) y las relaciones que vamos a 
utilizar para realizar la reunión natural, y sean R D S 
sus atributos en común. Supóngase que ambas relacio¬ 
nes están ordenadas en los atributos de R Pl S. Enton¬ 
ces su reunión se puede calcular mediante un proceso 
muy parecido a la etapa de mezcla del algoritmo de orde¬ 
nación-mezcla. 

El algoritmo de reunión por mezcla se muestra en la 
Figura 13.6. En este algoritmo, AtribsReunión se refie¬ 
re a los atributos en R H S y, a su vez, t s xi t r , donde t r 
y t s son las tupias que tienen los mismos valores en 
AtribsReunión, denota la concatenación de los atribu¬ 
tos de las tupias, seguido de una proyección para no 
incluir los atributos repetidos. El algoritmo de reunión 
por mezcla asocia un puntero con cada relación. Al 
comienzo, estos punteros apuntan a la primera tupia de 
sus respectivas relaciones. Según avanza el algoritmo, 
el puntero se mueve a través de la relación. De este modo 
se leen en S s un grupo de tupias de una relación con el 
mismo valor en los atributos de la reunión. El algorit¬ 
mo de la Figura 13.6 necesita que cada conjunto de 
tupias S s quepa en memoria principal; se examinará más 
tarde en este apartado extensiones del algoritmo que 
evitan este supuesto. Entonces, las tupias correspon¬ 
dientes de la otra relación (si las hay) se leen y se pro¬ 
cesan según se están leyendo. 

En la Figura 13.7 se muestran dos relaciones que 
están ordenadas en su atributo de la reunión al. Es ins¬ 
tructivo recorrer los pasos del algoritmo de reunión por 
mezcla con las relaciones que se muestran en la figura. 

Dado que las relaciones están ordenadas, las tupias 
con el mismo valor en los atributos de la reunión apa¬ 
recerán consecutivamente. De este modo solamente es 
necesario leer cada tupia en el orden una vez y, como 
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FIGURA 13.7. Relaciones ordenadas para la reunión por 
mezcla. 


resultado, leer también cada bloque solamente una vez. 
Puesto que sólo se hace un ciclo en ambos archivos, el 
método de reunión por mezcla resulta eficiente; el núme¬ 
ro de accesos a bloques es igual a la suma de los blo¬ 
ques en los dos archivos, b,. + b s . 

Si alguna de las relaciones de entrada roino está 
ordenada según los atributos de la reunión, se pueden 
ordenar primero y luego utilizar el algoritmo de reunión 
por mezcla. El algoritmo de reunión por mezcla tam¬ 
bién se puede extender fácilmente desde las reuniones 
naturales al caso más general de las equirreuniones. 

Supóngase que se aplica el esquema de reunión por 
mezcla al ejemplo de impositor xi cliente. Aquí el atri¬ 
buto de la reunión es nombre-cliente. Supóngase que 
las dos relaciones están ya ordenadas según el atributo 
de la reunión nombre-cliente. En este caso, la reunión 
por mezcla emplea un total de 400 + 100 = 500 acce¬ 
sos a bloques. Supóngase ahora que las relaciones no 
están ordenadas y que el tamaño de la memoria cae en 
el caso peor de tres bloques. Ordenar cliente emplea 400 
* (2 \log ,(400/3)] + 1) o 6.800 transferencias de blo¬ 
ques, con 400 transferencias más para escribir el resul¬ 
tado. Del mismo modo, ordenar impositor lleva 100 * 
(2|7og 2 (100/3)] + 1) o 1.300 transferencias de bloques, 
con 100 transferencias más para escribirlo. Así, el cos¬ 
te total si las relaciones no están ordenadas es de 9.100 
transferencias de bloques y el tamaño de memoria es 
sólo 3 bloques. 

Con un tamaño de memoria de 25 bloques, la orde¬ 
nación de cliente emplea 400 * (2 \log 2 (400/25)] + 1) 
= 1.200 transferencias de bloques, mientras que la orde¬ 
nación de impositor emplea 300 transferencias de blo¬ 
ques. Añadiendo el coste de escribir los resultados orde¬ 
nados y volverlos a leer da un total de 2.500 
transferencias de bloques si las relaciones no están orde¬ 
nadas y el tamaño de la memoria es de 25 bloques. 

Como se mencionó anteriormente, el algoritmo de 
reunión por mezcla de la Figura 13.6 necesita que el 
conjunto S s de todas las tupias con el mismo valor en 
los atributos de la reunión quepan en memoria princi¬ 
pal. Este requisito se puede alcanzar normalmente, inclu¬ 
so si la relación 5 es grande. Si no se puede cumplir, se 
tiene que realizar entre S s y las tupias de r una reunión 
en bucle anidado por bloques con los mismos valores 
en los atributos de la reunión. Como resultado, el cos¬ 
te de la reunión por mezcla aumenta. 

También es posible realizar una variación de la ope¬ 
ración reunión por mezcla en tupias desordenadas si 
existen índices secundarios en los dos atributos de la 
reunión. Así, se examinan los registros a través de los 
índices recuperándolos de manera ordenada. Sin embar¬ 
go, esta variación presenta un importante inconvenien¬ 
te, puesto que los registros podrían estar diseminados a 
través de los bloques del archivo. Por tanto, cada acce¬ 
so a una tupia podría implicar acceder a un bloque del 
disco, y esto es muy costoso. 

Para evitar este coste se puede utilizar una técnica 
de reunión por mezcla híbrida que combinase índices 
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con reunión por mezcla. Supóngase que una de las rela¬ 
ciones está ordenada; la otra está desordenada, pero tie¬ 
ne un índice secundario de árbol B + en los atributos de 
la reunión. El algoritmo híbrido de reunión por mez¬ 
cla fusiona la relación ordenada con las entradas hoja 
del índice secundario de árbol B + . El archivo resultan¬ 
te contiene tupias de la relación ordenada y direcciones 
de las tupias de la relación desordenada. Luego se orde¬ 
na el archivo resultante según las direcciones de las 
tupias de la relación desordenada, permitiendo así una 
recuperación eficiente de las correspondientes tupias, 
según el orden físico de almacenamiento, para comple¬ 
tar la reunión. Se deja como ejercicio las extensiones 
de esta técnica para tratar el caso de dos relaciones desor¬ 
denadas. 

13.5.5. Reunión por asociación 

Al igual que el algoritmo de reunión por mezcla, el algo¬ 
ritmo de reunión por asociación se puede utilizar para 
implementar reuniones naturales y equirreuniones. En 
el algoritmo de reunión por asociación se utiliza una 
función de asociación h para dividir las tupias de ambas 
relaciones. La idea fundamental es dividir las tupias de 
cada relación en conjuntos con el mismo valor de la fun¬ 
ción de asociación en los atributos de la reunión. 

Se supone que 

• h es una función de asociación que asigna a los 
AtribsReunión los valores {0, 1,..., n,}, donde los 
AtribsReunión denotan los atributos comunes de r 
y ^ utilizados en la reunión natural. 

• H r , H r ,..., H r denotan las particiones de las tupias 
de r, inicialménte todas vacías. Cada tupia t, E r 
se pone en la partición H r , donde i = h(t'{Atribs¬ 
Reunión]). 

• H s , H ,..., H s denotan las particiones de las tupias 
de s, inicialménte todas vacías. Cada tupia t s E 5 
se pone en la partición H s , donde i = h(t s [Atribs- 
Reunión]). 

La función de asociación h debería de tener las «bue¬ 
nas» propiedades de aleatoriedad y uniformidad que se 
discutieron en el Capítulo 12. La división de las rela¬ 
ciones se muestra de manera gráfica en la Ligura 13.8. 

La idea que está detrás del algoritmo de reunión por 
asociación es la que sigue. Supóngase que una tupia de 
r y una tupia de 5 satisfacen la condición de la reunión; 
por tanto, tendrán el mismo valor en los atributos de la 
reunión. Si el valor se asocia con algún valor i, la tupia 
de r tiene que estar en H r y la tupia de s en H s . De este 
modo solamente es necesario comparar las tupias de r 
en H r con las tupias de s en // A ; no es necesario com¬ 
pararlas con las tupias de s de otra partición. 

Por ejemplo, si i es una tupia de impositor, c una 
tupia de cliente y h una función de asociación en los 
atributos nombre-cliente de las tupias, solamente se tie¬ 
ne que comprobar i y c si h(c ) = h(i). Si h(c) * h(J), 



Particiones Particiones 

de r de s 


FIGURA 13.8. Particiones asociadas de relaciones. 


entonces c e i tienen valores distintos en el nombre- 
cliente. Sin embargo, si h(c) = h{i) hay que verificar que 
c e i tengan los mismos valores en los atributos de la 
reunión, ya que es posible que c e i tengan atributos 
nombre-cliente distintos con el mismo valor de la fun¬ 
ción de asociación. 

En la Ligura 13.9 se muestran los detalles del algo¬ 
ritmo de reunión por asociación para calcular la reu¬ 
nión natural de las relaciones rys. Como en el algorit¬ 
mo de reunión por mezcla, t r Xl t s denota la 
concatenación de los atributos de las tupias de t r y t s , 
seguido de la proyección para eliminar los atributos 
repetidos. Después de la división de las relaciones, el 
resto del código de reunión por asociación realiza una 
reunión en bucle anidado indexada separada en cada 
una de los partición pares i, con i = 0,..., n h . Para lograr 
esto, primero se construye un índice asociativo en cada 
H s y luego se prueba (es decir, se busca en H s ) con las 
tupias de H r . La relación s es la entrada para cons¬ 
truir y r es la entrada para probar. 

El índice asociativo en H s se construye en memoria, 
así que no es necesario acceder al disco para recuperar 
las tupias. La función de asociación utilizada para cons¬ 
truir este índice asociativo es distinta de la función de 
asociación h utilizada anteriormente, pero aún se apli¬ 
ca exclusivamente a los atributos de la reunión. A lo lar¬ 
go de la reunión en bucle anidado indexada, el sistema 
utiliza este índice asociativo para recuperar los regis¬ 
tros que concuerden con los registros de la entrada para 
probar. 

Las etapas de construcción y prueba necesitan sola¬ 
mente un único ciclo a través de las entradas para cons- 
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/* Partición de s */ 

for each tupia t s in s do begin 

i := h(t s [AtribsReunión]); 

H s¡ '■= H s . U {t s }; 

end 

/* Partición de r*t 

for each tupia t r in r do begin 

i := h(t r [AtribsReunión ]); 

H r . := H r . U {f r }; 

end 

/* Realizar la reunión de cada partición */ 

for /: = 0 to max do begin 

leer H s y construir un índice asociativo en memoria en él 
for each tupia f r in H r do begin 

explorar el índice asociativo en H s . para localizar todas las tupias t s tales que t s [AtribsReunión] = t r [AtribsReunión] 
for each tupia f s que concuerde in H s . do begin 
añadir t r N t s al resultado 

end 

end 

end 

FIGURA 13.9. Reunión por asociación. 


truir y probar. La extensión del algoritmo de reunión 
por asociación para calcular equirreuniones más gene¬ 
rales es directa. 

Se tiene que elegir el valor de n h lo suficientemente 
grande de tal modo que, para cada i, las tupias en la par¬ 
tición H s de la relación para construir, junto con el índi¬ 
ce asociativo de la partición, quepan en la memoria. 
Pero no tienen por qué caber en memoria las particio¬ 
nes de la relación para probar. Claramente, será mejor 
utilizar la relación de entrada más pequeña como la rela¬ 
ción para construir. Si el tamaño de la relación para cons¬ 
truir es de b s bloques, entonces para que cada una de las 
n h particiones tengan un tamaño menor o igual que M, 
n h debe ser al menos f bJM] . Con más exactitud, hay 
que tener en cuenta también el espacio adicional ocu¬ 
pado por el índice asociativo de la partición, incremen¬ 
tando n h según corresponda. Por motivos de simplici¬ 
dad muchas veces se ignora en estos análisis el requisito 
del espacio ocupado por el índice asociativo. 

13.5.5.1. División recursiva 

Si el valor de n h es mayor o igual que el número de mar¬ 
cos de página de la memoria, la división de las relacio¬ 
nes no se puede hacer en un solo ciclo, puesto que no 
habría suficientes páginas para memorias intermedias. 
En lugar de eso, la división se tiene que hacer median¬ 
te la repetición de ciclos. En un ciclo se puede dividir 
la entrada en tantas particiones como marcos de pági¬ 
na haya disponibles para utilizarlos como memorias 
intermedias de salida. Cada cajón generado por un ciclo 
se lee de manera separada y se divide de nuevo en el 
siguiente ciclo para crear particiones más pequeñas. La 
función de asociación utilizada en un ciclo es, por 
supuesto, diferente de la que se ha utilizado en el ciclo 
anterior. Se repite esta división de la entrada hasta que 
cada partición de la entrada para construir quepa en 
memoria. Esta división se llama división recursiva. 


Una relación no necesita división recursiva si M > n h 
+ l,o equivalentemente M > ( bJM) + 1, que se simpli¬ 
fica (de manera aproximada) a M> \/b s . Por ejemplo, 
considerando un tamaño de la memoria de 12 MB, divi¬ 
dido en bloques de 4 KB; contendría un total de 3 K 
(3072) bloques. Se puede utilizar una memoria de este 
tamaño para dividir relaciones de hasta 3 K * 3 K blo¬ 
ques de tamaño, que son 36 GB. Del mi smo m odo, una 
relación del tamaño de 1 GB necesita V256K bloques, 
o alrededor de 2 MB, para evitar la división recursiva. 

13.5.5.2. Gestión de desbordamientos 

Se produce el desbordamiento de una tabla de aso¬ 
ciación en la partición i de la relación para construir s, 
si el índice asociativo en H es más grande que la memo¬ 
ria principal. El desbordamiento de la tabla de asocia¬ 
ción puede ocurrir si hay muchas tupias en la relación 
para construir con los mismos valores en los atributos 
de la reunión, o si la función de asociación no tiene las 
propiedades de aleatoriedad y uniformidad. En cual¬ 
quier caso, algunas de las particiones tendrán más tupias 
que la media, mientras que otras tendrán menos; se dice 
entonces que la división está sesgada. 

Se puede controlar parcialmente el sesgo mediante 
el incremento del número de particiones de tal manera 
que el tamaño esperado de cada partición (incluyendo 
el índice asociativo en la partición) sea algo menor que 
el tamaño de la memoria. Por consiguiente, el número 
de particiones se incrementa en un pequeño valor lla¬ 
mado factor de escape, que normalmente está alrede¬ 
dor del 20 por ciento del número de particiones calcu¬ 
ladas con el método anterior. 

Incluso si se es conservador con los tamaños de las 
particiones utilizando un factor de escape, todavía pue¬ 
den ocurrir desbordamientos. Los desbordamientos de 
la tabla de asociación se pueden tratar mediante reso¬ 
lución del desbordamiento o evitación del desborda- 
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miento. La resolución del desbordamiento se realiza 
como sigue. Si H s . para cualquier i, resulta ser dema¬ 
siado grande, se divide de nuevo en particiones más 
pequeñas utilizando una función de asociación distin¬ 
ta. Del mismo modo, también se divide H r utilizando 
la nueva función de asociación, y solamente es necesa¬ 
rio reunir las tupias en las particiones concordantes. 

Por el contrario, la evitación del desbordamiento 
realiza la división más cuidadosamente, de tal manera 
que el desbordamiento nunca se produce en la fase de 
construcción. La evitación de desbordamiento se imple- 
menta mediante la división de la relación para construir 
5 inicialmente en muchas particiones pequeñas, para 
luego combinar algunas de estas particiones de tal mane¬ 
ra que cada partición combinada quepa en memoria. 
Además, la relación para probar r se tiene que combi¬ 
nar de la misma manera que se combinan las particio¬ 
nes de s, sin importar los tamaños de H r . 

Las técnicas de resolución y evitación podrían fallar 
en algunas particiones, si un gran número de las tupias 
en .v tuvieran el mismo valor en los atributos de la reu¬ 
nión. En ese caso, en lugar de crear un índice asociati¬ 
vo en memoria y utilizar una reunión en bucle anidado 
para reunir las particiones, se pueden utilizar otras téc¬ 
nicas de reunión, tales como la reunión en bucle anida¬ 
do por bloques, en esas particiones. 

13.5.5.3. Coste de una reunión por asociación 

Se considera ahora el coste de una reunión por asocia¬ 
ción. El análisis supone que no hay desbordamiento de 
la tabla de asociación. Primero se considera el caso en 
el que no es necesaria una división recursiva. La divi¬ 
sión de las dos relaciones ry s reclama una lectura com¬ 
pleta de ambas relaciones así como su posterior escri¬ 
tura. Este operación necesita 2 {b r + b s ) accesos a bloques, 
donde b r y b, denotan respectivamente el número de blo¬ 
ques que contienen registros de las relaciones ry s. Las 
fases de construcción y prueba leen cada una de las par¬ 
ticiones una vez, empleando b r + b s accesos adiciona¬ 
les. El número de bloques ocupados por las particiones 
podría ser ligeramente mayor que b r + b, debido a que 
los bloques están parcialmente ocupados. El acceso a 
estos bloques llenos en parte puede añadir un gasto adi¬ 
cional de 2 n h a lo sumo, ya que cada una de las n b par¬ 
ticiones podría tener un bloque lleno parcialmente que 
se tiene que escribir y leer de nuevo. Así, el coste esti¬ 
mado para una reunión por asociación es 

3 (b r + b s ) + 2n h 

La sobrecarga 2 n,, es muy pequeña comparada con 
b r + b s y se puede ignorar. 

Consideremos ahora el caso en el que se necesita la 
división recursiva. Cada ciclo reduce el tamaño de cada 
una de las particiones por un factor esperado de M - 1; 
esta reducción del tamaño se repite hasta que cada par¬ 
tición tenga como mucho un tamaño de M bloques. Por 
tanto, el número esperado de ciclos necesarios para divi¬ 


dir 5 es [ log M _ ,(h j - 1 ]. Puesto que cada bloque de ,v se 
lee y se escribe en cada ciclo, el número total de trans¬ 
ferencias de bloques para dividir ,v es 2 b s \log M _ - 1 ]. 
Como el número de ciclos para dividir r es el mismo que 
el número de pasadas para dividir s, se obtiene la siguien¬ 
te estimación del coste de la reunión: 

2 (b r + b s )\log M _,(b s ) - 1 ]+ b,. + b s 

Considérese, por ejemplo, la reunión cliente M 
impositor. Con un tamaño de memoria de 20 bloques, 
se puede dividir impositor en cinco partes, cada una de 
20 bloques, con un tamaño tal que caben en memoria. 
Así, sólo es necesario un ciclo para la división. De la 
misma manera la relación cliente se divide en cinco 
particiones, cada una de tamaño 80. Si se ignora el cos¬ 
te de escribir los bloques parcialmente llenos, el coste 
es 3(100 + 400) = 1.500 transferencias de bloques. 

Se puede mejorar la reunión por asociación si el 
tamaño de la memoria principal es grande. Cuando la 
entrada para construir se puede guardar por completo 
en memoria principal hay que poner n h a 0; de este modo 
el algoritmo de reunión por asociación se ejecuta rápi¬ 
damente, sin dividir las relaciones en archivos tempo¬ 
rales y sin importar el tamaño de la entrada para pro¬ 
bar. El coste estimado desciende a b r + b s . 

13.5.5.4. Reunión por asociación híbrida 

El algoritmo de reunión por asociación híbrida reali¬ 
za otra optimización; es útil cuando los tamaños de la 
memoria son relativamente grandes pero no cabe toda 
la relación para construir en memoria. La fase de divi¬ 
sión del algoritmo de reunión por asociación necesita 
de un bloque de memoria como memoria intermedia 
para cada partición que se cree, más un bloque de memo¬ 
ria como memoria intermedia de entrada. Por tanto, se 
necesitan n h + 1 bloques de memoria para dividir las dos 
relaciones. Si la memoria es más grande que n h + 1, se 
puede utilizar el resto de la memoria (M - n h - 1 blo¬ 
ques) para guardar en memorias intermedias la prime¬ 
ra partición de la entrada para construir (esto es, H So ), 
así que no es necesario escribirla ni leerla de nuevo. Más 
aún, la función de asociación se diseña de tal manera 
que el índice asociativo en // quepa en M—n h — 1 blo¬ 
ques, así que, al final de la división de s, H e stá en 
memoria por completo y se puede construir un índice 
asociativo en H.. 

Cuando r se divide de nuevo, las tupias en H no se 
escriben en disco; en su lugar, según se van generando, 
el sistema las utiliza para examinar el índice asociativo 
residente en memoria de H y para generar las tupias 
de salida de la reunión. Después de utilizarlas para la 
prueba, se descartan las tupias, así que la partición H 
no ocupa ningún espacio en memoria. De este modo se 
ahorra un acceso de lectura y otro de escritura para cada 
bloque de H y H . Las tupias en otras particiones se 
escriben de la manera usual para reunirlas más tarde. El 
ahorro de la reunión por asociación híbrida puede ser 
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importante si la entrada para construir es ligeramente 
mayor que la memoria. 

Si el tamaño de la relación para construir es b s , n h es 
aproximadamente igual a bJM. Así, la reunión por aso¬ 
ciación híbrida es más útil si M » bJM, o si M» Vb s , 
donde la notación » significa mucho más grande que. 
Por ejemplo, supóngase que el tamaño del bloque es de 
4 KB y que el tamaño de la relación para construir es 
de 1 GB. Entonces, el algoritmo híbrido de reunión por 
asociación es útil si el tamaño de la memoria es clara¬ 
mente mayor que 2 MB; las memorias de 100 MB o 
más son comunes en las computadoras de hoy en día. 

Considérese de nuevo la reunión cliente X irnposi- 
tor. Con una memoria de 25 bloques de tamaño, se pue¬ 
de dividir impositor en cinco particiones, cada una de 
20 bloques, y con la primera de las particiones de la rela¬ 
ción para construir almacenada en memoria. Ocupa 20 
bloques de memoria; un bloque se utiliza para la entra¬ 
da y cuatro bloques más para guardar en memorias inter¬ 
medias cada partición. De manera similar se divide la 
relación cliente en cinco particiones cada una de tama¬ 
ño 80, la primera de las cuales se utiliza precisamente 
para probar, en lugar de escribirse y leerse de nuevo. 
Ignorando el coste de escribir los bloques parcialmente 
llenos, el coste es de 3(80 + 320) + 20 + 80 = 1.300 blo¬ 
ques transferidos, en lugar de las 1.500 transferencias de 
bloques sin la optimización de asociación híbrida. 

13.5.6. Reuniones complejas 

Las reuniones en bucle anidado y en bucle anidado por 
bloques son útiles sean cuales sean las condiciones de 
la reunión. Las otras técnicas de reunión son más efi¬ 
cientes que las reuniones en bucle anidado y sus varian¬ 
tes, aunque sólo se pueden utilizar con condiciones sim¬ 
ples, tales como las reuniones naturales o las 
equirreuniones. Se pueden implementar reuniones con 


condiciones de la reunión más complejas, tales como 
conjunciones y disyunciones, utilizando las técnicas efi¬ 
cientes de la reunión mediante la aplicación de las téc¬ 
nicas desarrolladas en el Apartado 13.3.4 para el mane¬ 
jo de selecciones complejas. 

Considérese la siguiente reunión con una condición 
conjuntiva: 

r 1x1 s, a e 2 a ... a e„ s 

Se pueden aplicar una o más de las técnicas de reunión 
descritas anteriormente en cada condición individual r 
M e s, r x 02 s, r xi ft; s, y así sucesivamente. Se calcula el 
resultado total de la reunión calculando primero el resul¬ 
tado de una de estas reuniones simples r x fl s; cada par 
de tupias del resultado intermedio se compone de una 
tupia de r y otra de s. El resultado total de la reunión con¬ 
siste en las tupias del resultado intermedio que satisfa¬ 
cen el resto de condiciones 

0i A a 9 ¡ _ i a 6 ¡+l a ... a e n 

Estas condiciones se pueden ir comprobando según se 
generan las tupias de r x a - 5. 

Una reunión cuya condición es una disyunción se 
puede calcular como se indica a continuación. Consi¬ 
dérese 

r 1X1 e, v e, v... v e„ s 

La reunión se puede calcular como la unión de los regis¬ 
tros de las reuniones r X a . a individuales: 

(r x 0| s) U (r X a „ s) U ... U (r X 9| s ) 

Los algoritmos para calcular la unión de relaciones se 
describen en el Apartado 13.6. 


13.6. OTRAS OPERACIONES 


Otras operaciones relaciónales y operaciones relació¬ 
nales extendidas —tales como eliminación de duplica¬ 
dos, proyección, operaciones sobre conjuntos, reunión 
externa y agregación— se pueden implementar según 
se describe en los Apartados 13.6.1 al 13.6.5. 

13.6.1. Eliminación de duplicados 

Se puede implementar fácilmente la eliminación de 
duplicados utilizando la ordenación. Las tupias idénti¬ 
cas aparecerán consecutivas durante la ordenación, 
pudiéndose eliminar todas las copias menos una. Con 
la ordenación-mezcla externa, se pueden eliminar los 
duplicados mientras se crea una secuencia antes de que 
ésta se escriba en el disco, reduciendo así el número de 


bloques transferidos. El resto de duplicados se pueden 
suprimir durante la etapa de reunión/mezcla, así que el 
resultado final estará libre de repeticiones. El coste esti¬ 
mado en el peor de los casos para la eliminación de 
duplicados es el mismo que el coste estimado en el peor 
caso para la ordenación de una relación. 

Se puede implementar también la eliminación de 
duplicados utilizando la asociación de una manera simi¬ 
lar al algoritmo de reunión por asociación. Primero, se 
divide la relación basándose en una función de asocia¬ 
ción en la tupia entera. Luego, se lee cada partición, y 
se construye un índice asociativo en memoria. Mientras 
se construye el índice asociativo se inserta una tupia sola¬ 
mente si no estaba ya presente. En otro caso se descar¬ 
ta. Después de que todas las tupias de la relación se hayan 
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procesado, las tupias en el índice asociativo se escriben 
al resultado. El coste estimado es el mismo que el cos¬ 
te de procesar (división y lectura de cada partición) la 
relación para construir en una reunión por asociación. 

Debido al coste relativamente alto de la eliminación 
de duplicados, SQL requiere una petición explícita del 
usuario para suprimir los duplicados; en caso contrario 
se conservan los duplicados. 

13.6.2. Proyección 

Se puede implementar la proyección fácilmente reali¬ 
zando la proyección de cada tupia, pudiendo originar 
una relación con registros repetidos y suprimiendo des¬ 
pués los registros duplicados. La eliminación de dupli¬ 
cados se puede llevar a cabo según se ha descrito en el 
Apartado 13.6.1. Si los atributos de la lista de proyec¬ 
ción incluyen una clave de la relación, no se produci¬ 
rán duplicados; por tanto no será necesario eliminarlos. 
La proyección generalizada (discutida en el Apartado 
3.3.1) se puede implementar de la misma manera que 
las proyecciones. 

13.6.3. Operaciones sobre conjuntos 

Se pueden implementar las operaciones unión, inter¬ 
sección y diferencia de conjuntos ordenando primero 
ambas relaciones y examinando después cada relación 
para producir el resultado. En r U s, cuando una explo¬ 
ración concurrente en ambas relaciones descubre la mis¬ 
ma tupia en los dos archivos, solamente se conserva una 
de las tupias. Por otra parte, el resultado de r Pl 5 con¬ 
tendrá únicamente aquellas tupias que aparezcan en 
ambas relaciones. De la misma manera se implementa 
la diferencia de conjuntos, r - s, guardando aquellas 
tupias de r que estén ausentes en 5. 

Para todas estas operaciones solamente se necesita 
una exploración en cada relación de entrada, así el cos¬ 
te es b r + b s . Si las relaciones no están ordenadas ini¬ 
cialmente, hay que incluir el coste de la ordenación. Se 
puede utilizar cualquier otro orden en la evaluación de 
la operación de conjuntos, siempre que las dos entradas 
tengan la misma ordenación. 

La asociación proporciona otra manera de imple¬ 
mentar estas operaciones sobre conjuntos. El primer 
paso en cada caso es dividir las dos relaciones utilizan¬ 
do la misma función de asociación y de este modo crear 
las particiones ff,, ... , H r y H s¡ ,... , H s . Lo siguiente 
se realiza en cada partición i= 0, 1,..., n h . 

• r U s 

1. Construir un índice asociativo en memoria en 
ffr 

2. Añadir las tupias en H s . al índice asociativo sola¬ 
mente si no estaban ya presentes. 

3. Añadir las tupias del índice asociativo al resul¬ 
tado. 


• fíls 

1. Construir un índice asociativo en memoria en 

H r , 

2. Para cada tupia en H s¡ probar el índice asocia¬ 
tivo y pasar la tupia al resultado únicamente si 
ya estaba presente en el índice. 

• r-s 

1. Construir un índice asociativo en memoria en 

H r , 

2. Para cada tupia en I f probar el índice asocia¬ 
tivo y, si la tupia está presente en el índice, 
suprimirla del índice asociativo. 

3. Añadir las tupias restantes del índice asociati¬ 
vo al resultado. 

13.6.4. Reunión externa 

Recordemos las operaciones de reunión externa que se 
describieron en el Apartado 3.3.3. Por ejemplo, la reu¬ 
nión externa por la izquierda cliente 3X impositor con¬ 
tiene la reunión de cliente e impositor y adicionalmen¬ 
te, para cada tupia t de cliente que no concuerde con 
alguna tupia en impositor (es decir, donde no esté nom¬ 
bre-cliente en impositor ), se añade la siguiente tupia t¡ 
al resultado. Para todos los atributos en el esquema de 
cliente, la tupia t ] tiene los mismos valores que la tupia 
t. El resto de atributos (del esquema de impositor ) de la 
tupia ti contienen el valor nulo. 

Se pueden implementar las operaciones de reu¬ 
nión externa empleando una de las dos estrategias 
siguientes. 

1. Calcular la reunión correspondiente, y luego aña¬ 
dir más tupias al resultado de la reunión hasta obte¬ 
ner la reunión extema resultado. Considérese la ope¬ 
ración de reunión externa por la izquierda y dos 
relaciones: r(R) y s(S). Para evaluar r s, se cal¬ 
cula primero r x n s y se guarda este resultado como 
la relación temporal q¡. A continuación se calcula 
r-I\ R (qj), que produce las tupias de r que no par¬ 
ticiparon en la reunión. Se puede utilizar cualquier 
algoritmo para calcular las reuniones. Luego se 
rellenan cada una de estas tupias con valores nulos 
en los atributos de 5 y se añaden a q¡ para obtener 
el resultado de la reunión extema. 

La operación reunión externa por la derecha 
r ixn g s es equivalente a 5 nxi 0 r y, por tanto, se puede 
implementar de manera simétrica a la reunión 
externa por la izquierda. También se puede im¬ 
plementar la operación reunión externa completa 
r nxL g s calculando la reunión r M 6 iy añadiendo 
entonces tupias adicionales de operaciones reu¬ 
nión externa por la izquierda y por la derecha, al 
igual que antes. 

2. Modificar los algoritmos de la reunión. Así, es 
fácil extender los algoritmos de reunión en bucle 
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anidado para calcular la reunión externa por la 
izquierda. Las tupias de la relación externa que 
no concuerdan con ninguna tupia de la relación 
interna se escriben en la salida después de haber 
sido completadas con valores nulos. Sin embar¬ 
go, es difícil extender la reunión en bucle anida¬ 
do para calcular la reunión externa completa. 

Las reuniones extemas naturales completas y las reu¬ 
niones externas con una condición de equirreunión, se 
pueden calcular mediante extensiones de los algoritmos 
de reunión por mezcla y reunión por asociación. La reu¬ 
nión por mezcla se puede extender para realizar la reu¬ 
nión extema completa como se muestra a continuación. 
Cuando se está produciendo la mezcla de las dos rela¬ 
ciones, las tupias de la relación que no encajan con nin¬ 
guna tupia de la otra relación se pueden completar con 
valores nulos y escribirse en la salida. Del mismo modo, 
se puede extender la reunión por mezcla para calcular 
las reuniones externas por la izquierda y por la derecha 
mediante la copia de las tupias que no concuerden (relle¬ 
nadas con valores nulos) desde solamente una de las 
relaciones. Puesto que las relaciones están ordenadas, 
es fácil detectar si una tupia coincide o no con alguna 
de las tupias de la otra relación. Por ejemplo, cuando se 
hace una reunión por mezcla de cliente e impositor, las 
tupias se leen según el orden de nombre-cliente, siendo 
fácil de comprobar para cada tupia si hay alguna tupia 
coincidente. 

El coste estimado para implementar reuniones exter¬ 
nas utilizando el algoritmo de reunión por mezcla es el 
mismo que para la correspondiente reunión. La única 
diferencia está en el tamaño del resultado y, por tanto, en 
los bloques transferidos para copiarlos que no se han teni¬ 
do en cuenta en las estimaciones anteriores del coste. 

La extensión del algoritmo de reunión por asocia¬ 
ción para calcular reuniones extemas se deja como ejer¬ 
cicio (Ejercicio 13.11). 

13.6.5. Agregación 

Retomemos el operador de agregación (j discutido en 
el Apartado 3.3.2. Por ejemplo, la operación 


nombre-sucursal Q sum (saldo) ( ClientCl ) 

agmpa tupias de cuenta por sucursal y calcula el saldo 
total de todas las cuentas en cada sucursal. 

La operación agregación se puede implementar de 
una manera parecida a la eliminación de duplicados. 
Se utiliza la ordenación o la asociación, al igual que 
se hizo para la supresión de duplicados, pero basán¬ 
dose ahora en la agrupación de atributos ( nombre- 
sucursal en el ejemplo anterior). Sin embargo, en lugar 
de eliminar las tupias con el mismo valor en los atri¬ 
butos de la agrupación, se reúnen en grupos y se apli¬ 
can las operaciones agregación en cada grupo para 
obtener el resultado. 

El coste estimado para la implementación de la ope¬ 
ración agregación es el mismo coste de la eliminación 
de duplicados para las funciones de agregación como 
min, max, sum, count y avg. 

En lugar de reunir todas las tupias en grupos y apli¬ 
car entonces las funciones de agregación, se pueden 
implementar las funciones de agregación min, max, 
sum, count y avg sobre la marcha según se construyen 
los grupos. Para el caso de sum, min y max, cuando se 
encuentran dos tupias del mismo grupo se sustituyen 
por una sola tupia con sum, min o max, respectiva¬ 
mente, de las columnas que se están agregando. Para la 
operación count, se mantiene una cuenta incremental 
para cada grupo con tupias descubiertas. Por último, la 
operación avg se implementa calculando la suma y la 
cuenta de valores sobre la marcha, para dividir final¬ 
mente la suma entre la cuenta para obtener la media. 

Si todas las tupias del resultado caben en memoria, 
las implementaciones basadas en ordenación y las basa¬ 
das en asociación no necesitan escribir ninguna tupia 
en disco. Según se leen las tupias se pueden insertar en 
un estructura ordenada de árbol o en un índice asocia¬ 
tivo. Así, cuando se utilizan las técnicas de agregación 
sobre la marcha, solamente es necesario almacenar una 
tupia para cada uno de los grupos. Por tanto, la estruc¬ 
tura ordenada de árbol o el índice asociativo van a caber 
en memoria y se puede procesar la agregación con sólo 
b r transferencias de bloques, en lugar de las 3 b r trans¬ 
ferencias que se necesitarían de otra manera. 


13.7. EVALUACIÓN DE EXPRESIONES 


Hasta aquí se ha estudiado cómo llevar a cabo opera¬ 
ciones relaciónales individuales. Ahora se considera 
cómo evaluar una expresión que contiene varias ope¬ 
raciones. La manera evidente de evaluar una expresión 
es simplemente evaluar una operación a la vez en un 
orden apropiado. El resultado de cada evaluación se 
materializa en una relación temporal para su inme¬ 
diata utilización. Un inconveniente de esta aproxima¬ 
ción es la necesidad de construir relaciones tempora¬ 


les, que (a menos que sean pequeñas) se tienen que 
escribir en disco. Un enfoque alternativo es evaluar 
varias operaciones de manera simultánea en un cauce, 
con los resultados de una operación pasados a la 
siguiente, sin la necesidad de almacenar relaciones tem¬ 
porales. 

En los Apartados 13.7.1 y 13.7.2 se consideran ambos 
enfoques, materialización y encarnamiento. Se verá que 
el coste de estos enfoques puede diferir sustancialmen- 
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te, pero también que existen casos donde sólo la mate¬ 
rialización es posible. 

13.7.1. Materialización 

Intuitivamente es fácil de entender cómo evaluar una 
expresión observando una representación gráfica de la 
expresión en un árbol de operadores. Considérese la 
expresión 

^-nombre-cliente (o S aid 0 <2500 {cuenta) x cliente) 

que se muestra en la Figura 13.10. 

Si se aplica el enfoque de la materialización, se 
comienza por las operaciones de la expresión de nivel 
más bajo (al fondo del árbol). En el ejemplo solamen¬ 
te hay una de estas operaciones; la operación selección 
en cuenta. Las entradas de las operaciones de nivel más 
bajo son las relaciones de la base de datos. Se ejecutan 
estas operaciones utilizando los algoritmos ya estudia¬ 
dos, almacenando sus resultados en relaciones tempo¬ 
rales. Luego se utilizan estas relaciones temporales para 
ejecutar las operaciones del siguiente nivel en el árbol, 
cuyas entradas son ahora o bien relaciones temporales 
o bien relaciones almacenadas en la base de datos. En 
este ejemplo, las entradas de la reunión son la relación 
cliente y la relación temporal producida por la selec¬ 
ción en cuenta. Ahora se puede evaluar la reunión 
creando otra relación temporal. 

Repitiendo este proceso se calcularía finalmente la 
operación en la raíz del árbol, obteniendo el resultado 
final de la expresión. En el ejemplo se consigue el resul¬ 
tado final mediante la ejecución de la operación pro¬ 
yección de la raíz utilizando como entrada la relación 
temporal creada por la reunión. 

Una evaluación como la descrita se llama evalua¬ 
ción materializada, puesto que los resultados de cada 
operación intermedia se crean (materializan) para utili¬ 
zarse a continuación en la evaluación de las operacio¬ 
nes del siguiente nivel. 

El coste de una evaluación materializada no es sim¬ 
plemente la suma de los costes de las operaciones invo¬ 
lucradas. Cuando se calcularon los costes estimados de 
los algoritmos se ignoró el coste de escribir el resulta- 


t^nombre-cliente 


X 



°ss/rfo< 2 5 oo cliente 


cuenta 

FIGURA 13.10. Representación gráfica de una expresión. 


do de la operación en disco. Para calcular el coste de 
evaluar una expresión como la que se ha hecho hay que 
añadir los costes de todas las operaciones, incluyendo 
el coste de escribir los resultados intermedios en disco. 
Supóngase que los registros del resultado se acumulan 
en una memoria intermedia y que cuando ésta se llena, 
los registros se escriben en el disco. El coste de copiar 
el resultado se puede estimar en n r / f r , donde n r es el 
número aproximado de tupias de la relación resultado 
y f. es el factor de bloqueo de la relación resultado, es 
decir, el número de registros de r que caben en un blo¬ 
que. 

La memoria intermedia doble (usando dos memo¬ 
rias intermedias, una donde progresa la ejecución del 
algoritmo mientras que la otra se está copiando) per¬ 
mite que el algoritmo se ejecute más rápidamente 
mediante la ejecución en paralelo de acciones en la UCP 
con acciones de E/S. 

13.7.2. Encauzamiento 

Se puede mejorar la eficiencia de la evaluación de la 
consulta mediante la reducción del número de archivos 
temporales que se producen. Se lleva a cabo esta reduc¬ 
ción con la combinación de varias operaciones relació¬ 
nales en un encauzamiento de operaciones, en el que se 
pasan los resultados de una operación a la siguiente ope¬ 
ración del encauzamiento. Esta evaluación, como se ha 
descrito, se denomina evaluación encauzada. La com¬ 
binación de operaciones en un encauzamiento elimina 
el coste de leer y escribir relaciones temporales. 

Por ejemplo, considérese la reunión de un par de 
relaciones seguida de una proyección (TT aí a2 ( r x s)). 
Si se aplicara la materialización, la evaluación impli¬ 
caría la creación de una relación temporal para guar¬ 
dar el resultado de la reunión y la posterior lectura del 
resultado para realizar la proyección. Estas operacio¬ 
nes se pueden combinar como sigue. Cuando la opera¬ 
ción reunión genera una tupia del resultado, se pasa 
inmediatamente esa tupia al operador de proyección 
para su procesamiento. Mediante la combinación de la 
reunión y de la proyección, se evita la creación de resul¬ 
tados intermedios, creando en su lugar el resultado final 
directamente. 

13.7.2.1. Implementación del encauzamiento 

Se puede implementar el encauzamiento construyendo 
una única y compleja operación que combine las ope¬ 
raciones que constituyen el encauzamiento. Aunque este 
enfoque aproximación podría ser factible en muchas 
situaciones, es deseable en general usar de nuevo el 
código en operaciones individuales en la construcción 
del encauzamiento. Por lo tanto, cada operación del 
encauzamiento se modela como un proceso aislado o 
una hebra en el sistema, que toma un flujo de tupias de 
sus entradas encauzadas y produce un flujo de tupias 
como salida. Para cada pareja de operaciones adyacen¬ 
tes en el encauzamiento se crea una memoria interme- 
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dia para guardar las tupias que se envían de una opera¬ 
ción a la siguiente. 

En el ejemplo de la Figura 13.10, las tres operacio¬ 
nes se pueden situar en un encauzamiento, en el que los 
resultados de la selección se pasan a la reunión según 
se generan. Por su parte, los resultados de la reunión se 
envían a la proyección según se van generando. Así, los 
requisitos de memoria son bajos, ya que los resultados 
de una operación no se almacenan por mucho tiempo. 
Sin embargo, como resultado del encauzamiento, las 
entradas de las operaciones no están disponibles todas 
a la vez para su procesamiento. 

Los encauzamientos se pueden ejecutar de alguno de 
los siguientes modos: 

1. Bajo demanda 

2. Desde los productores 

En un encauzamiento bajo demanda, el sistema 
reitera peticiones de tupias desde la operación de la cima 
del encauzamiento. Cada vez que una operación recibe 
una petición de tupias, calcula la siguiente tupia (o 
tupias) a devolver y la envía. Si las entradas de la ope¬ 
ración no están encauzadas, la(s) siguiente(s) tupla(s) a 
devolver se calcula(n) de las relaciones de entrada mien¬ 
tras se lleva cuenta de lo que se ha remitido hasta el 
momento. Si alguna de sus entradas está encauzada, la 
operación también hace peticiones de tupias desde sus 
entradas encauzadas. Así, utilizando las tupias recibi¬ 
das en sus entradas encauzadas, la operación calcula sus 
tupias de salida y las envía hasta su padre. 

En un encauzamiento por los productores, los ope¬ 
radores no esperan a que se produzcan peticiones para 
producir tupias, en su lugar generan las tupias impa¬ 
cientemente. Cada operación del fondo del encauza¬ 
miento genera continuamente tupias de salida y las 
ponen en su memoria intermedia de salida hasta que se 
llena. Una operación en cualquier otro nivel del encau¬ 
zamiento obtiene sus tupias de entrada de un nivel infe¬ 
rior del encauzamiento hasta llenar su memoria inter¬ 
media de salida. Una vez que la operación ha utilizado 
una tupia de su entrada encauzada, la elimina de ella. 
En cualquier caso, una vez que la memoria intermedia 
de salida esté llena, la operación espera hasta que su 
operación padre elimine las tupias de la memoria inter¬ 
media para hacer más espacio a nuevas tupias. En este 
momento, la operación genera más tupias hasta que se 
llene la memoria intermedia de nuevo. Este proceso se 
repite por una operación hasta que se hayan generado 
todas las tupias de salida. 

El sistema necesita cambiar de una operación a otra 
solamente cuando se llena una memoria intermedia de 
salida o cuando una memoria intermedia de entrada está 
vacía y se necesitan más tupias para generar las tupias 
de salida. En un sistema de procesamiento paralelo, las 
operaciones del encauzamiento se pueden ejecutar con¬ 
currentemente en distintos procesadores (véase el Capí¬ 
tulo 20). 


Se puede imaginar el encauzamiento por los pro¬ 
ductores como una inserción de datos de abajo hacia 
arriba en el árbol de operaciones, mientras que el encau¬ 
zamiento bajo demanda se puede pensar como una 
extracción de datos desde la cima del árbol de ope¬ 
raciones. Mientras que las tupias se generan impacien¬ 
temente en el encauzamiento por los productores, se 
generan de forma perezosa, bajo demanda, en el encau¬ 
zamiento bajo demanda. 

Cada operación en un encauzamiento bajo deman¬ 
da se puede implementar como un iterador, que pro¬ 
porciona las siguientes funciones: abrir(), siguiente() y 
cerrar(). Después de una llamada a abrir(), cada llama¬ 
da a siguiente() devuelve la siguiente tupia de salida de 
la operación. La implementación de la operación vigen¬ 
te produce llamadas a siguiente() desde sus entradas, 
cuando necesita tupias de entrada. La función cerrar() 
comunica al iterador que no necesita más tupias. De 
este modo, el iterador mantiene el estado de su ejecu¬ 
ción entre las llamadas, de tal manera que las sucesi¬ 
vas peticiones siguiente() reciben sucesivas tupias resul¬ 
tado. 

Por ejemplo, en un iterador que implemente la ope¬ 
ración selección usando la búsqueda lineal, la opera¬ 
ción abrir() inicia una exploración de archivo y el esta¬ 
do del iterador registra el punto en el que el archivo se 
ha explorado. Cuando se llama a la función siguiente() 
la exploración del archivo continúa a continuación del 
punto anterior; cuando se encuentre la siguiente tupia 
que cumpla la selección al explorar el archivo, se 
devuelve la tupia después de almacenar el punto don¬ 
de se encontró en el estado del iterador. Una operación 
abrir() del iterador de reunión por mezcla abriría sus 
entradas y, si aún no están ordenadas, también las orde¬ 
naría. En las llamadas a siguiente() se devolvería el 
siguiente par de tupias coincidentes. La información 
de estado consistiría en volver a la posición en que se 
ha explorado cada entrada. 

Los detalles de la implementación de iteradores se 
dejan para completar en el Ejercicio 13.12. El encau¬ 
zamiento bajo demanda se utiliza normalmente más que 
el encauzamiento por los productores, ya que es más 
fácil de implementar. 

13.7.2.2. Algoritmos de evaluación para 
el encauzamiento 

Considérese una operación reunión cuya entrada del 
lado izquierdo está encauzada. Puesto que está encau¬ 
zada, no toda la entrada está disponible al mismo tiem¬ 
po para el procesamiento de la operación reunión. Al 
no estar disponible, se limita la elección del algoritmo 
de reunión a emplear. Por ejemplo, no se puede usar la 
reunión por mezcla si las entradas no están ordenadas, 
puesto que no es posible ordenar la relación hasta que 
todas las tupias estén disponibles; así, en efecto, se con¬ 
vierte el encauzamiento en materialización. Sin embar¬ 
go, se puede utilizar la reunión en bucle anidado inde- 


337 


FUNDAMENTOS DE BASES DE DATOS 


xada: Según se reciben las tupias por el lado izquierdo 
de la reunión se pueden utilizar para indexar el lado 
derecho de la relación y para generar las tupias resulta¬ 
do de la reunión. Este ejemplo ilustra que las eleccio¬ 
nes respecto del algoritmo a utilizar para una operación 
y las elecciones respecto del encauzamiento no son inde¬ 
pendientes. 

Las restricciones en los algoritmos de evaluación 
que se pueden utilizar es un factor determinante del 
encauzamiento. Como resultado, a pesar de las apa¬ 
rentes ventajas del encauzamiento, hay casos donde la 
materialización alcanza un coste total menor. Supón¬ 
gase que se desea realizar la reunión de r y s, y que la 
entrada r está encauzada. Si se utiliza una reunión en 
bucle anidado indexada para llevar a cabo el encauza¬ 
miento, podría ser necesario un acceso a disco para cada 
tupia de la relación de entrada encauzada. El coste de 
esta técnica es n, * AA ¡, donde AA¡ es la altura de índi¬ 
ce en 5 . Con la materialización, el coste de copiar r sería 
b r Con una técnica de reunión, como la reunión por 
asociación, podría ser posible realizar la reunión con 
un coste aproximado de 3 (b r + b s ). Si n, es realmente 
mayor que 4 b r + 3 b s , la materialización sería más eco¬ 
nómica. 

El uso eficiente del encauzamiento necesita la utili¬ 
zación de algoritmos de evaluación que puedan gene¬ 
rar tupias de salida según se están recibiendo tupias por 
las entradas de la operación. Se pueden distinguir dos 
casos: 

1. Solamente una de las entradas de la reunión está 
encauzada. 

2. Las dos entradas de la reunión están encauzadas. 


Si únicamente una de las entradas de la reunión está 
encauzada, la reunión en bucle anidado indexada es la 
elección más natural. Si las tupias de entrada encauza¬ 
das están ordenadas según los atributos de la reunión 
y la condición de la reunión es una equirreunión, tam¬ 
bién se puede emplear la reunión por mezcla. La reu¬ 
nión por asociación híbrida se puede utilizar con la 
entrada encauzada como la relación para probar. Sin 
embargo, las tupias que no están en la primera parti¬ 
ción se enviarán a la salida solamente después de que 
la relación de entrada encauzada se reciba por com¬ 
pleto. La reunión por asociación híbrida es útil si las 
entradas no encauzadas caben completamente en 
memoria, o si al menos la mayoría de las entradas caben 
en memoria. 

Si ambas entradas están encauzadas, la elección de 
los algoritmos de reunión está más limitada. Si ambas 
entradas están ordenadas en los atributos de la reunión 
y la condición de la reunión es una equirreunión, enton¬ 
ces se puede usar la reunión por mezcla. Otra técnica 
alternativa es la reunión encauzada, que se muestra 
en laLigura 13.11. El algoritmo supone que las tupias 
de entrada de ambas relaciones, r y s, están encauza¬ 
das. Las tupias disponibles de ambas relaciones se dejan 
listas para su procesamiento en una cola simple. Así 
mismo, se generan unas entradas de la cola especiales, 
llamadas Fin,, y Fin s , que sirven como marcas de fin de 
archivo y que se insertan en la cola después de que se 
hayan generado todas las tupias de r y s (respectiva¬ 
mente). Para una evaluación eficaz se deberían cons¬ 
truir los índices apropiados en las relaciones ry s. Según 
se añaden tupias a r y a i se deben mantener los índi¬ 
ces actualizados. 


hecho r := falso; 
hecho . := falso; 
r;= 0; 
s := 0; 

resultado := 0; 

while not hecho r or not hecho s do 
begin 

if la cola está vacía then esperar hasta que la cola no esté vacía; 
f := entrada de la cima de la cola; 
if f = Fin, then hecho, := cierto 

else ¡f f = Fin s then hecho s := cierto 
else ¡f fes de la entrada r 
then 

begin 

r;= rU {f}; 

resultado ;= resultado U ({f} XI s); 

end 

else /* t es de la entrada s */ 
begin 

s := s U {f}; 

resultado ;= resultado U [r X {t}); 

end 

end 


FIGURA 13.11. Algoritmo de reunión encauzada. 
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13.8. RESUMEN 


• La primera acción que el sistema debe realizar en una 
consulta es traducirla en su formato intemo, que (para 
sistemas de bases de datos relaciónales) está basado 
normalmente en el álgebra relacional. En el proceso 
de generación del formato interno de la consulta, el 
analizador comprueba la sintaxis, verifica que los 
nombres de relación que figuran en la consulta son 
nombres de relaciones de la base de datos, etcétera. 
Si la consulta se expresó en términos de una vista, el 
analizador sustituye todas las referencias al nombre 
de la vista con su expresión del álgebra relacional para 
calcularla. 

• Dada una consulta, generalmente hay diversos méto¬ 
dos para calcular la respuesta. Es responsabilidad del 
sistema transformar la consulta proporcionada por el 
usuario en otra consulta equivalente que se pueda eje¬ 
cutar de un modo más eficiente. El Capítulo 14 estu¬ 
dia la optimización de consultas. 

• Se pueden procesar consultas que impliquen selec¬ 
ciones sencillas mediante una búsqueda lineal, una 
búsqueda binaria o utilizando índices. Así mismo se 
pueden manejar selecciones más complejas median¬ 
te uniones e intersecciones de los resultados de selec¬ 
ciones simples. 

• Se pueden ordenar relaciones que sean más grandes 
que la memoria utilizando el algoritmo de ordena¬ 
ción-mezcla externa. 

• Las consultas que impliquen una reunión natural se 
pueden procesar de varias maneras, dependiendo de 
la disponibilidad de índices y del tipo de almacena¬ 
miento físico utilizado para las relaciones. 

• Si la reunión resultante es casi tan grande como el 
producto cartesiano de las dos relaciones, una estra¬ 
tegia de reunión en bucle anidado por bloques podría 
ser ventajosa. 


• Si hay índices disponibles, se puede utilizar la reu¬ 
nión en bucle anidado indexada. 

• Si las relaciones están ordenadas, sería deseable 
una reunión por mezcla. Además, podría ser útil 
ordenar una relación antes que calcular una reunión 
(para permitir el uso de una estrategia de reunión 
por mezcla). 

• El algoritmo de reunión por asociación divide la rela¬ 
ción en varias particiones, de tal manera que cada par¬ 
tición de una de las relaciones quepa en memoria. La 
división se lleva a cabo con una función de asocia¬ 
ción en los atributos de la reunión, de tal modo que 
los pares de particiones correspondientes se puedan 
reunir independientemente. 

• La eliminación de duplicados, la proyección, las ope¬ 
raciones de conjuntos (unión, intersección y diferencia) 
se pueden realizar mediante ordenación o asociación. 

• Las operaciones de reunión externa se pueden imple- 
mentar como extensiones simples de los algoritmos 
de reunión. 

• Las técnicas de asociación y ordenación son duales, 
en el sentido en que muchas operaciones como la eli¬ 
minación de duplicados, agregación, reuniones y reu¬ 
niones extemas se pueden implementar mediante aso¬ 
ciación o bien por ordenación. 

• Una expresión se puede evaluar mediante materia¬ 
lización, donde el sistema calcula el resultado de 
cada subexpresión y lo almacena en disco, y des¬ 
pués lo usa para calcular el resultado de la expre¬ 
sión padre. 

• El encauzamiento ayuda a evitar la escritura en dis¬ 
co de los resultados de muchas subexpresiones, usan¬ 
do los resultados de la expresión padre como si se 
estuviesen generando. 


TÉRMINOS DE REPASO 


• Árbol de operadores 

• Búsqueda binaria 

• Búsqueda lineal 

• Ciclos 

• E/S paralela 

• E/S secuencial 

• Equirreunión 

• Evaluación encauzada 

- Cauce bajo demanda (perezoso, extracción) 

- Cauce por productor (impaciente, inserción) 

- Iterador 


• Evaluación materializada 

• Evaluación de primitivas 

• Evitación del desbordamiento 

- Factor de escape 

- Probar 

- Resolución del desbordamiento 

- Sesgo 

• Exploración de archivos 

• Exploración de índices 

• índice compuesto 

• Intersección de identificadores 
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• Mediadas del coste de las consultas 

• Memoria intermedia doble 

• Mezcla de n vías 

• Motor de ejecución de consultas 

• Ordenación externa 

• Ordenación-mezcla externa 

• Plan de ejecución de consultas 

• Plan de evaluación de consultas 

• Procesamiento de consultas 

• Reunión por asociación 

- Construir 

- Desbordamiento de la tabla asociativa 

- División recursiva 

- Entrada para construir 

- Entrada para probar 


• Reunión por asociación híbrida 

• Reunión en bucle anidado 

• Reunión en bucle anidado por bloques 

• Reunión en bucle anidado indexada 

• Reunión encauzada 

• Reunión por mezcla 

• Reunión por mezcla híbrida 

• Reunión por ordenación-mezcla 

• Rutas de acceso 

• Selección conjuntiva 

• Selección disyuntiva 

• Selecciones usando índices 


EJERCICIOS 


13.1. ¿Por qué no hay que obligar a los usuarios a que eli¬ 
jan explícitamente una estrategia de procesamiento 
de la consulta? ¿Hay casos en los que es deseable que 
los usuarios sepan el coste de las distintas estrategias 
posibles? Razónese la respuesta. 

13.2. Considérese la siguiente consulta SQL para la base de 
datos bancaria: 

select T.nombre-sucursal 
from sucursal T, sucursal S 

where T.activo > S.activo and S.ciudad-sucursal 
= «Arganzuela» 

Escríbase una expresión del álgebra relacional equi¬ 
valente a la dada que sea más eficiente. Justifiqúese 
la elección. 

13.3. ¿Cuáles son las ventajas e inconvenientes de los índi¬ 
ces asociativos en relación con índices de árbol B + ? 
¿Cómo podría el tipo de índice influenciar en la elec¬ 
ción de una estrategia de procesamiento de una con¬ 
sulta? 

13.4. Supóngase (para simplificar este ejercicio) que sola¬ 
mente cabe una tupia en un bloque y que la memoria 
puede contener como máximo tres marcos de página. 
Muéstrense las secuencias creadas en cada ciclo del 
algoritmo de ordenación-mezcla cuando se aplica para 
ordenar el primer atributo de las siguientes tupias: 
(canguro, 17), (ualabí, 21), (emú, 1), (wombat, 13), 
(ornitorrinco, 3), (león, 8), (jabalí, 4), (cebra, 11), (koa¬ 
la, 6), (hiena, 9), (cálao, 2), (babuino, 12). 

13.5. Dadas las relaciones r,(A, B, C ) y r 2 (C, D, E) con las 
siguientes propiedades: r t tiene 20.000 tupias, r 2 tiene 
45.000 tupias, 25 tupias de r¡ caben en un bloque y 30 
tupias de r, que caben en un bloque. Estímese el núme¬ 


ro de accesos a bloques requeridos utilizando las 
siguientes estrategias para la reunión r, M r 2 : 

a. Reunión en bucle anidado 

b. Reunión en bucle anidado por bloques 

c. Reunión por mezcla 

d. Reunión por asociación 

13.6. Diséñese una variante del algoritmo híbrido de reu¬ 
nión por mezcla para el caso en el que las dos rela¬ 
ciones no están ordenadas según el orden físico de 
almacenamiento, pero ambas tienen un índice secun¬ 
dario ordenado en los atributos de la reunión. 

13.7. El algoritmo de reunión en bucle anidado indexada 
descrito en el Apartado 13.5.3 puede ser ineficiente 
si el índice fuera secundario y hubiese varias tupias 
con el mismo valor en los atributos de la reunión. 
¿Por qué es ineficiente? Descríbase una forma de 
reducir el coste de recuperar las tupias de la relación 
más interna utilizando ordenación. ¿Bajo qué condi¬ 
ciones sería este algoritmo más eficiente que la reu¬ 
nión por mezcla híbrida? 

13.8. Estímese el número de accesos a bloques necesitados 
por la solución del Ejercicio 13.6 para r¡ txi r 2 , don¬ 
de r¡ y r 2 son como las relaciones definidas en el Ejer¬ 
cicio 13.5. 

13.9. Sean ry s dos relaciones sin índices que no están orde¬ 
nadas. Suponiendo una memoria infinita ¿cuál es la 
manera más económica (en términos de operaciones 
de E/S) para calcular r X¡ si ¿Cuánta memoria se 
necesita en este algoritmo? 

13.10. Supóngase que hay un índice de árbol B + disponible 
en ciudad-sucursal de la relación sucursal y que no 
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hay más índices. ¿Cuál sería el mejor modo de mane¬ 
jar las siguientes selecciones con negaciones? 

(ciudad-sucursal < «Arganzuela») ( SUCUfSCll ) 
tX, (dudad-sucursal = «Arganzuela») \SUCUrSQl) 

CX, (dudad-sucursal < «Arganzuela» v activo < 5000) {SUCUFSül) 

13.11. El algoritmo de reunión por asociación descrito en el 
Apartado 13.5.5 calcula la reunión natural de dos rela¬ 
ciones. Descríbase cómo extender el algoritmo de 
reunión por asociación para calcular la reunión exter¬ 
na por la izquierda, la reunión externa por la derecha 
y la reunión externa completa. (Sugerencia: se pue¬ 


de mantener información adicional con cada tupia en 
el índice asociativo para detectar si alguna tupia en 
la relación para probar concuerda con alguna tupia 
del índice asociativo.) Compruébese el algoritmo con 
las relaciones cliente e impositor. 

13.12. Escríbase el pseudocódigo para un iterador que imple- 
mente la reunión en bucle anidado indexada, donde 
la relación externa esté encauzada. Utilícense las fun¬ 
ciones de iterador estándares en el pseudocódigo. 
Muéstrese el estado del iterador entre las llamadas. 

13.13. Diséñense algoritmos basado en ordenación y aso¬ 
ciación para el cálculo de la operación división. 


NOTAS BIBLIOGRÁFICAS 


Todos los procesadores de consultas deben analizar 
instrucciones del lenguaje de consulta y deben traducir¬ 
las a su formato interno. El análisis de los lenguajes de 
consulta difiere poco del análisis de los lenguajes de pro¬ 
gramación tradicionales. La mayoría de los libros sobre 
compiladores, como Aho et al. [1986], tratan las princi¬ 
pales técnicas de análisis y presentan la optimización des¬ 
de el punto de vista de los lenguajes de programación. 

Knuth [1973] presenta un excelente descripción de 
algoritmos de ordenación externa, incluyendo una opti¬ 
mización que puede originar secuencias iniciales que 
son (en media) el doble del tamaño de la memoria. Basa¬ 
dos en estudios del rendimiento realizados a mediados 
de 1970, los sistemas de bases de datos de esa época 
utilizaban solamente reunión en bucle anidado y reu¬ 
nión por mezcla. Estos estudios, que estuvieron rela¬ 
cionados con el desarrollo de System R, determinaron 
que tanto la reunión en bucle anidado como la reunión 
por mezcla casi siempre proporcionaban el método de 
reunión óptimo [Blasgen y Eswaran 1976]; por tanto, 
estos son los dos únicos algoritmos de reunión imple- 
mentados en System R. Sin embargo, el estudio de Sys¬ 
tem R no incluyó el análisis de los algoritmos de reu¬ 
nión por asociación. Actualmente, estos algoritmos se 
consideran muy eficientes. 


Los algoritmos de reunión por asociación se desa¬ 
rrollaron inicialmente para sistemas de bases de datos 
paralelos. La técnica de reunión por asociación se des¬ 
cribe en Kitsuregawa et al. [1983] y en Shapiro [1986] 
se describen extensiones incluyendo la reunión por 
asociación híbrida. Resultados más recientes de Zeller 
y Gray [1990] y de Davison y Graefe [1994] descri¬ 
ben técnicas de reunión por asociación que se pueden 
adaptar a la memoria disponible, que es importante 
en sistemas donde se pueden ejecutar a la vez varias 
consultas. Graefe et al. [1998] describe el uso en 
Microsoft SQL Server de las reuniones por asociación 
y los equipos de asociación, que permiten el encau- 
zamiento de las reuniones por asociación usando la 
misma división para todas las reunión en una secuen¬ 
cia encauzada. 

Graefe [1993] presenta una excelente revisión de las 
técnicas de evaluación de consultas. Una revisión ante¬ 
rior de las técnicas de procesamiento de consultas apa¬ 
rece en Jarke y Koch [1984]. 

El procesamiento de consultas en bases de datos en 
memoria principal se trata en DeWitt et al. [1984] y 
Whang y Krishnamurthy [1990]. Kim [1982] y Kim 
[1984] describen estrategias de reunión y el uso óptimo 
de la memoria principal disponible. 
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OPTIMIZACIÓN DE CONSULTAS 


L a optimización de consultas es el proceso de selección del plan de evaluación de las 
consultas más eficiente de entre las muchas estrategias generalmente disponibles para el 
procesamiento de una consulta dada, especialmente si la consulta es compleja. No se 
espera que los usuarios escriban las consultas de modo que puedan procesarse de manera efi¬ 
ciente. Por el contrario, se espera que el sistema cree un plan de evaluación de las consultas que 
minimice el coste de la evaluación de las consultas. Aquí es donde entra en acción la optimi¬ 
zación de consultas. 

Un aspecto de la optimización de las consultas tiene lugar en el nivel del álgebra relacio- 
nal, donde el sistema intenta hallar una expresión que sea equivalente a la expresión dada, 
pero de ejecución más eficiente. Otro aspecto es la elección de una estrategia detallada para 
el procesamiento de la consulta, como puede ser la selección del algoritmo que se utilizará 
para ejecutar una operación, la selección de los índices concretos que se van a emplear, etcé¬ 
tera. 

La diferencia en coste (en términos de tiempo de evaluación) entre una estrategia buena 
y una mala suele ser sustancial, y puede ser de varios órdenes de magnitud. Por tanto, mere¬ 
ce la pena que el sistema pase una cantidad importante de tiempo en la selección de una bue¬ 
na estrategia para el procesamiento de la consulta, aunque esa consulta sólo se ejecute una 
vez. 


14.1. VISIÓN GENERAL 


Considérese la expresión del álgebra relacional para la 
consulta «Hallar los nombres de todos los clientes que 
tengan una cuenta en cualquier sucursal ubicada en 
Arganzuela». 

0 nombre-cliente ciudad-sucursal «ArganZUela» 

(,sucursal x (cuenta X impositor))) 

Esta expresión crea una relación intermedia de gran 
tamaño, sucursal X cuenta X impositor. Sin embargo, 
sólo nos interesan unas pocas tupias de esta relación (las 
correspondientes a las sucursales ubicadas en Argan¬ 
zuela), y sólo en uno de los seis atributos de la relación. 
Dado que sólo nos preocupan las tupias de la relación 
sucursal que corresponden a las sucursales ubicadas en 
Arganzuela, no hace falta considerar las tupias que no 
tienen ciudad-sucursal = «Arganzuela». Al reducir el 
número de tupias de la relación sucursal a las que hace 
falta tener acceso, se reduce el tamaño del resultado 
intermedio. La consulta queda ahora representada por 
la expresión de álgebra relacional: 

O nombre-cliente (° ciudad-sucursal = 

«Arganzuela» ( SUCUrSül )) X (CUdlta X ÍmpOSÍtOr )) 

que es equivalente a la expresión algebraica original, 
pero que genera relaciones intermedias de menor tama¬ 


ño. La Figura 14.1 muestra la expresión inicial y la trans¬ 
formada. 

Dada una expresión del álgebra relacional, es labor 
del optimizador de consultas diseñar un plan de eva¬ 
luación de consultas que calcule el mismo resultado que 
la expresión dada, y que sea la manera menos costosa 
de generar ese resultado (o, como mínimo, que no sea 
mucho más costoso que la manera menos costosa). 

Para escoger entre los diferentes planes de evalua¬ 
ción de consultas el optimizador tiene que estimar el 
coste de cada plan de evaluación. El cálculo del coste 


n nombre-cliente ^ nombre-cliente 


O dudad-sucursal = Arganzuela X 



cuenta impositor sucursal cuenta impositor 

(a) Árbol inicial (b) Árbol transformado 

de la expresión de la expresión 


FIGURA 14.1. Expresiones equivalentes. 


343 






FUNDAMENTOS DE BASES DE DATOS 


exacto de evaluación de un plan no suele resultar posi¬ 
ble sin evaluar realmente el plan. En lugar de eso, los 
optimizadores hacen uso de la información estadística 
sobre las relaciones, como los tamaños de las relacio¬ 
nes y las profundidades de los índices, para realizar una 
buena estimación del coste de cada plan. El acceso a los 
discos, que resulta lento en comparación con el acceso 
a la memoria, suele dominar el coste del procesamien¬ 
to de las consultas. 

En el Apartado 14.2 se describe el modo de estimar 
las estadísticas de los resultados de cada operación en 
los planes de consultas. El empleo de estas estadísti¬ 
cas con las fórmulas de costes del Capítulo 13 permi¬ 
te estimar los costes de cada operación. Los costes 
individuales se combinan para determinar el coste esti¬ 
mado de la evaluación de la expresión de álgebra rela- 
cional dada, como se indicó previamente en el Apar¬ 
tado 13.7. 

Para hallar el plan de evaluación de consultas menos 
costoso el optimizador necesita generar planes alter¬ 
nativos que produzcan el mismo resultado que la expre¬ 
sión dada y escoger el menos costoso. La generación 
de planes de evaluación de consultas implica dos etapas: 
(1) la generación de expresiones que sean equivalen¬ 
tes lógicamente a la expresión dada y (2) la anotación 
de las expresiones resultantes en maneras alternativas 


de generar planes de evaluación de consultas alterna¬ 
tivos. Las dos etapas están entrelazadas en el optimi¬ 
zador de consultas -se generan y se anotan unas expre¬ 
siones, luego se generan y se anotan otras expresiones, 
etcétera. 

Para implementar la primera etapa el optimizador de 
consultas debe generar expresiones equivalentes a la 
expresión dada. Lo hace mediante las reglas de equi¬ 
valencia, que especifican el modo de transformar una 
expresión en otra equivalente lógicamente. Estas reglas 
se describen en el Apartado 14.3.1. En el Apartado 14.4 
se describe el modo de escoger un plan de evaluación 
de consultas. Se puede escoger uno basado en el coste 
estimado de los planes. Dado que el coste es una esti¬ 
mación, el plan seleccionado no es necesariamente el 
menos costoso; no obstante, siempre y cuando las esti¬ 
maciones sean buenas, es probable que el plan sea el 
menos costoso, o no mucho más costoso. Esta optimi¬ 
zación, denominada optimización basada en costes, 
se describe en el Apartado 14.4.2. 

Las vistas materializadas ayudan a acelerar el pro¬ 
cesamiento de ciertas consultas. En el Apartado 14.5 se 
estudia el modo de «mantener» las vistas materializa¬ 
das -es decir, mantenerlas actualizadas- y la manera de 
llevar a cabo la optimización de consultas con las vis¬ 
tas materializadas. 


14.2. ESTIMACIÓN DE LAS ESTADÍSTICAS DE LOS RESULTADOS 
DE LAS EXPRESIONES 


El coste de cada operación depende del tamaño y de 
otras estadísticas de sus valores de entrada. Dada una 
expresión como a x (b xi c), para estimar el coste de 
combinar a con (b XI c ) hay que hacer estimaciones de 
estadísticas como el tamaño de b XI c. 

En este apartado se relacionarán en primer lugar algu¬ 
nas estadísticas de las relaciones de bases de datos que 
se almacenan en los catálogos de los sistemas de bases 
de datos y luego se mostrará el modo de utilizar las esta¬ 
dísticas para estimar estadísticas de los resultados de 
varias operaciones relaciónales. 

Una cosa que quedará clara más adelante en este 
apartado es que las estimaciones no son muy precisas, 
ya que se basan en suposiciones que puede que no se 
cumplan exactamente. El plan de evaluación de con¬ 
sultas que tenga el coste estimado de ejecución más 
reducido puede, por tanto, no tener el coste real de eje¬ 
cución más bajo. Sin embargo, la experiencia real ha 
mostrado que, aunque las estimaciones no sean muy 
precisas, los planes con los costes estimados más redu¬ 
cidos tienen costes de ejecución reales que son los más 
reducidos o se hallan cercanos a los costes reales de eje¬ 
cución más bajos. 


14.2.1. Información del catálogo 

Los catálogos de los SGDD almacenan la siguiente 
información estadística sobre las relaciones de las bases 
de datos: 

• n r , el número de tupias de la relación r. 

• b r , el número de bloques que contienen tupias de 
la relación r. 

• t r , el tamaño de cada tupia de la relación r en bytes. 

• f r , el factor de bloqueo de la relación /; es decir, el 
número de tupias de la relación r que caben en un 
bloque. 

• V (A, r), el número de valores distintos que apare¬ 
cen en la relación r para el atributo A. Este valor 
es igual que el tamaño de n A (r). Si A es una clave 
de la relación r, V (A, r) es n r 

La última estadística, V (A, r), también puede calcular¬ 
se para conjuntos de atributos, si se desea, en vez de 
sólo para atributos aislados. Por tanto, dado un conjun¬ 
to de atributos, A, V (A, r) es el tamaño de II A (r). 
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Si se supone que las tupias de la relación r se alma¬ 
cenan físicamente juntas en un archivo, se cumple la 
ecuación siguiente: 



Las estadísticas sobre los índices, como las alturas de 
los árboles B + y el número de páginas hojas de los índi¬ 
ces, también se conservan en el catálogo. 

Si se desean conservar estadísticas precisas, por tan¬ 
to, cada vez que se modifica una relación también hay 
que actualizar las estadísticas. Esta actualización supo¬ 
ne una sobrecarga sustancial. Por tanto, la mayor parte 
de los sistemas no actualizan las estadísticas con cada 
modificación. En lugar de eso, actualizan las estadísti¬ 
cas durante los periodos de poca carga del sistema. En 
consecuencia, puede que las estadísticas utilizadas para 
escoger una estrategia de procesamiento de consultas 
no sean completamente exactas. Sin embargo, si no se 
producen demasiadas actualizaciones en los intervalos 
entre las actualizaciones de las estadísticas, éstas serán 
lo bastante precisas como para proporcionar una buena 
estimación de los costes relativos de los diferentes pla¬ 
nes. 

La información estadística anotada aquí está simpli¬ 
ficada. Los optimizadores verdaderos suelen conservar 
información estadística adicional para mejorar la preci¬ 
sión de sus estimaciones de costes de los planes de eva¬ 
luación. Por ejemplo, algunas bases de datos almacenan 
la distribución de los valores de cada atributo en forma 
de histograma: en los histogramas los valores del atri¬ 
buto se dividen en una serie de rangos, y con cada ran¬ 
go el histograma asocia el número de tupias cuyo valor 
del atributo se halla en ese rango. Como ejemplo de his¬ 
tograma, el rango de valores del atributo edad de la rela¬ 
ción persona puede dividirse en 0-9, 10-19,.. . , 90-99 
(suponiendo una edad máxima de 99). Con cada rango 
se almacena un recuento del número de tupias persona 
cuyos valores de edad se hallan en ese rango. Sin la infor¬ 
mación del histograma un optimizador tendría que supo¬ 
ner que la distribución de los valores es uniforme; es 
decir, que cada rango tiene el mismo recuento. 

14.2.2. Estimación del tamaño de la selección 

La estimación del tamaño del resultado de una opera¬ 
ción de selección depende del predicado de la selección. 
En primer lugar se considerará un solo predicado de 
igualdad, luego un solo predicado de comparación y, 
finalmente, combinaciones de predicados. 

* °A = a( r ) : Si se supone una distribución uniforme 
de los valores (es decir, que cada valor aparece con 
igual probabilidad), se puede estimar que el resul¬ 
tado de la selección tiene n r /V (A, r) tupias, supo¬ 
niendo que el valor a aparece en el atributo A de 
algún registro de r. La suposición de que el valor 


a de la selección aparece en algún registro suele ser 
cierta, y las estimaciones de costes suelen hacerla 
de manera implícita. No obstante, no suele ser rea¬ 
lista suponer que cada valor aparece con igual pro¬ 
babilidad. El atributo nombre-sucursal de la rela¬ 
ción cuenta es un ejemplo en el que esta suposición 
no es válida. Hay una tupia de la relación cuenta 
para cada cuenta. Resulta razonable esperar que las 
sucursales grandes tengan más cuentas que las 
pequeñas. Por tanto, algunos valores nombre-sucur¬ 
sal aparecen con mayor probabilidad que otros. 
Pese al hecho de que la suposición de distribución 
uniforme no suele ser correcta, resulta una aproxi¬ 
mación razonable de la realidad en muchos casos, 
y ayuda a mantener la representación relativamen¬ 
te sencilla. 

* ° a<v ( r ) : Considérese una selección de la forma 
o A < v (r). Si el valor real utilizado en la compara¬ 
ción (v) está disponible en el momento de la esti¬ 
mación del coste, puede hacerse una estimación 
más precisa. Los valores mínimo y máximo (min 
(A, r) y max (A, r)) del atributo pueden almace¬ 
narse en el catálogo. Suponiendo que los valores 
están distribuidos de manera uniforme, se puede 
estimar el número de registros que cumplirán la 
condición A < v como 0 si v < min (A, r), como 
n r si v > max (A, r) y como 

v - min (A, r) 

n r ■ - 

max (A, r) - min (A, r) 

en otro caso. 

En algunos casos, como cuando la consulta for¬ 
ma parte de un procedimiento almacenado, puede 
que el valor v no esté disponible cuando se optimice 
la consulta. En esos casos, se supondrá que aproxi¬ 
madamente la mitad de los registros cumplen la con¬ 
dición de comparación. Es decir, se supone que el 
resultado tiene n r !2 tupias; la estimación puede resul¬ 
tar muy imprecisa, pero es lo mejor que se puede 
hacer sin más información. 

• Selecciones complejas: 

- Conjunción: Una selección conjuntiva es una 
selección de la forma 

°0, A 0 2 A ■■■ A8 n ( r ) 

Se puede estimar el tamaño del resultado de esta 
selección: Para cada 6¡, se estima el tamaño de 
la selección o d¡ (r), denotada por s¡, como se ha 
descrito anteriormente. Por tanto, la probabili¬ 
dad de que una tupia de la relación satisfaga la 
condición de selección d¡ es sJn r . 

La probabilidad anterior se denomina selec¬ 
tividad de la selección o g . (r). Suponiendo que 
las condiciones sean independientes entre sí, la 
probabilidad de que una tupia satisfaga todas las 
condiciones es simplemente el producto de todas 
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estas probabilidades. Por tanto, se estima el 
número de tupias de la selección completa como 

s, * s 2 * ••• * s n 
n r * - 

K 

- Disyunción: Una selección disyuntiva es una 
selección de la forma 

° b ] v e 2 v...ve„( r ) 

Una condición disyuntiva se satisface por la 
unión de todos los registros que satisfacen las 
condiciones individuales y simples 6¡. 

Como anteriormente, admitamos que s¡/n r 
denota la probabilidad de que una tupia satisfa¬ 
ga la condición 6¡. La probabilidad de que la 
tupia satisfaga la disyunción es, pues, 1 menos 
la probabilidad de que no satisfaga ninguna de 
las condiciones: 

1 _(1 _ÍL) * (i * ... * (1 - -Í2-) 

n r n r n r 

Multiplicando este valor por n r se obtiene el 
número estimado de tupias que satisfacen la 
selección. 

- Negación: En ausencia de valores nulos el resul¬ 
tado de una selección o g (r) es simplemente las 
tupias de r que no están en o g (/). Ya se sabe el 
modo de estimar el número de tupias de o g (r). 
El número de tupias de o e (/) se estima, por lo 
tanto, que es n (r) menos el número estimado de 
tupias de o g ( r ). 

Se pueden tener en cuenta los valores nulos 
estimando el número de tupias para las que la 
condición 6 se evalúa como desconocida, y res¬ 
tar ese número de la estimación anterior que 
ignora los valores nulos. La estimación de ese 
número exige conservar estadísticas adiciona¬ 
les en el catálogo. 

14.2.3. Estimación del tamaño de las reuniones 

En este apartado se verá el modo de estimar el tamaño 
del resultado de una reunión. 

El producto cartesiano rxs contiene n r * n s tupias. 
Cada tupia derxi ocupa t r + t s bytes, de donde se pue¬ 
de calcular el tamaño del producto cartesiano. 

La estimación del tamaño de una reunión natural 
resulta algo más complicada que la estimación del tama¬ 
ño de una selección del producto cartesiano. Sean r ( R ) 
y 5 (S) dos relaciones. 

• Si El S = 0 —es decir, las relaciones no tienen 
ningún atributo en común— entonces r XI 5 es 
igual que r D 5, y se puede utilizar la técnica de 
estimación anterior para los productos cartesianos. 

• Si R Cl S es una clave de R, entonces se sabe que 
cada tupia de 5 se combinará como máximo con 


una tupia de r. Por tanto, el número de tupias de 
r N inoes mayor que el número de tupias de 5. 
El caso de que R fl S sea una clave de S es simé¬ 
trico al caso que se acaba de describir. Si R D S 
forma una clave externa de S, que haga referencia 
a R, el número de tupias de r XI 5 es exactamente 
el mismo que el número de tupias de 5. 

• El caso más difícil es que üílSno sea una clave 
de R ni de S. En este caso se supone, como se hizo 
para las selecciones, que todos los valores aparecen 
con igual probabilidad. Considérese una tupia t de 
r y supóngase que R Cl S = {A}. Se estima que la 
tupia t produce 


V (A, s) 

tupias en r >< s, ya que este número es el número 
promedio de tupias de i- con un valor dado para los 
atributos A. Considerando todas las tupias de r se 
estima que hay 

>h- * >h 

V (A, s) 

tupias in r tx s. Obsérvese que, si se invierten los 
papeles de r y de 5 en la estimación anterior, se 
obtiene una estimación de 

>h * >h 

V (A, r) 

tupias en r IX 5. Estas dos estimaciones son dife¬ 
rentes si V (A, r)íV (A, s). Si esta situación se pro¬ 
duce, probablemente haya tupias pendientes que 
no participen en la reunión. Por tanto, probable¬ 
mente la menor de la dos estimaciones sea la más 
precisa. 

La estimación anterior del tamaño de la reu¬ 
nión puede ser demasiado elevada si los valores 
de V (A, r ) para el atributo A en r tienen pocas 
tupias en común con los valores de V (A, s) para 
el atributo A en s. No obstante, es improbable que 
se dé esta situación en la realidad, ya que las tupias 
pendientes o bien no existen o sólo constituyen 
una pequeña fracción de las tupias, en la mayor 
parte de las relaciones reales. Lo que es más 
importante todavía, la estimación anterior depen¬ 
de de la suposición de que todos los valores apa¬ 
recen con igual probabilidad. Hay que utilizar téc¬ 
nicas más sofisticadas para la estimación del 
tamaño si esta suposición no resulta válida. 

Se puede estimar el tamaño de una reunión theta 
r XI e s reescribiendo la reunión como o g (rxs) y 
empleando las estimaciones de tamaño de los produc¬ 
tos cartesianos junto con las estimaciones de tamaño 
de las selecciones, que se vieron en el Apartado 14.2.2. 

Para ilustrar todas estas maneras de estimar el tama¬ 
ño de las reuniones, considérese la expresión 
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impositor x cliente 


Supóngase que se dispone de la siguiente información 
de catálogo sobre las dos relaciones: 


n c uente= 10000. 


f diente = 25, lo que implica que b cliente = 
= 10000/25 = 400. 


^impositor 5000. 


f¡mpositor = 50, lo que implica que b impositor ■■ 
= 5000/50 = 100. 


• V (nombre-cliente, impositor) = 2.500, lo que 
implica que, en promedio, cada cliente tiene dos 
cuentas. 


Supóngase también que nombre-cliente de impositor es 
una clave extema de cliente. 

En el ejemplo de impositor M cliente, nombre-clien¬ 
te de impositor es una clave externa que hace referen¬ 
cia a cliente', por tanto, el tamaño del resultado es exac¬ 
tamente n impositor , que es 5000. 

Calculemos ahora las estimaciones de tamaño de 
impositor tx cliente sin utilizar la información sobre las 
claves extemas. Como V ( nombre-cliente, impositor ) = 
2500 y V ( nombre-cliente, cliente) = 10000, las dos esti¬ 
maciones que se consiguen son 5000 * 10000/2500 = 
20000 y 5000 * 10000/10000 = 5000, y se escoge la 
menor. En este caso, la menor de las estimaciones es 
igual que la que se calculó anteriormente a partir de la 
información sobre las claves externas. 


14.2.4. Estimación del tamaño de otras 
operaciones 

A continuación se esbozará el modo de estimar el tama¬ 
ño de los resultados de otras operaciones del álgebra 
relacional. 

Proyección: El tamaño estimado (número de registros 
de las tupias) de una proyección de la forma fXi (r) 
es V (A, r), ya que la proyección elimina los duplica¬ 
dos. 

Agregación: El tamaño de A Q F (r) es simplemente V 
(A, r), ya que hay una tupia de A Q F ( r ) P or cada valor 
distinto de A. 

Operaciones de conjuntos: Si las dos entradas de una 
operación de conjuntos son selecciones de la misma 
relación se puede reescribir la operación de conjun¬ 
tos como disyunciones, conjunciones o negaciones. 
Por ejemplo, o g (r) U a 0i (r) puede reescribirse como 
cr 0 v ( r )- De manera parecida, se pueden reescribir 
las intersecciones como conjunciones y la diferencia 
de conjuntos empleando la negación, siempre que las 
dos relaciones que participan en la operación de con¬ 
juntos sean selecciones de la misma relación. Luego 
se pueden utilizar las estimaciones de las selecciones 


que impliquen conjunciones, disyunciones y nega¬ 
ciones del Apartado 14.2.2. 

Si las entradas no son selecciones de la misma rela¬ 
ción se estiman los tamaños de esta manera: El tama¬ 
ño estimado de r U s es la suma de los tamaños de r 
y de El tamaño estimado de r H s es el mínimo de 
los tamaños de r y de 5. El tamaño estimado de r - 5 
es el mismo tamaño de r. Las tres estimaciones pue¬ 
den ser imprecisas, pero proporcionan cotas superio¬ 
res para los tamaños. 

Reunión externa: El tamaño estimado de r nx s es el 
tamaño de r X 5 más el tamaño de r; el de r x: 5 es 
simétrico, mientras que el de r üxc s es el tamaño de 
r X 5 más los tamaños de r y de 5 . Las tres estima¬ 
ciones pueden ser imprecisas, pero proporcionan 
cotas superiores para los tamaños. 

14.2.5. Estimación del número de valores 
distintos 

Para las selecciones el número de valores distintos de 
un atributo (o de un conjunto de atributos) A en el resul¬ 
tado de una selección, V(A, o g (r)), puede estimarse de 
las maneras siguientes: 

• Si la condición de selección 6 obliga a que A adop¬ 
te un valor especificado (por ejemplo, A = 3), V(A, 
o g (r)) = 1. 

• Si 6 obliga a que A adopte un valor de entre un 
conjunto especificado de valores (por ejemplo, 
(A=lVA = 3VA = 4)), entonces V (A, o g (r)) 
se define como el número de valores especifica¬ 
dos. 

• Si la condición de selección 6 es de la forma A op 
v, donde op es un operador de comparación, V (A, 
o g (r)) se estima que es V (A, r) * s, donde 5 es la 
selectividad de la selección. 

• En todos los demás casos de selecciones se da por 
supuesto que la distribución de los valores de A es 
independiente de la distribución de los valores para 
los que se especifican las condiciones de selección 
y se utiliza una estimación aproximada de min 
(V (A, r), n 0a(rj ). Se puede obtener una estimación 
más precisa para este caso utilizando la teoría de 
la probabilidad, pero la aproximación anterior fun¬ 
ciona bastante bien. 

Para las reuniones el número de valores distintos de 
un atributo (o de un conjunto de atributos) A en el resul¬ 
tado de una reunión, V (A, r X s), puede estimarse de 
las maneras siguientes: 

• Si todos los atributos de A proceden de r, V (A, r 
X s) se estima como min (V (A, r ), n r MS ), y de 
manera parecida si todos los atributos de A proce¬ 
den de> s, V (A, r x 5 ) se estima que es min (V (A, 

s), n rKS ). 
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• Si A contiene atributos Al de r y A2 de s, enton¬ 
ces V (A, r X s) se estima como min (U(A1, r) * 
V (A2 - Al, s), V (Al -A2, r) * V(A2, s), n rtiS ) 
Obsérvese que algunos atributos pueden estar 
en Al y en A2, y que A1-A2 y A2-A1 denotan, 
respectivamente, a los atributos de A que sólo 
proceden de r y a los atributos de A que sólo pro¬ 
ceden de Nuevamente, se pueden obtener esti¬ 
maciones más precisas utilizando la teoría de la 
probabilidad, pero las aproximaciones anterio¬ 
res funcionan bastante bien. 


Las estimaciones de los distintos valores son directas 
para las proyecciones: son iguales en H A (/) que en r. 
Lo mismo resulta válido para los atributos de agru¬ 
pación de las agregaciones. Para los resultados de 
suma, cuenta y promedio, se puede suponer, por sen¬ 
cillez, que todos los valores agregados son distintos. 
Para min (A) y max (A), el número de valores distin¬ 
tos puede estimarse como min (V (A, r), V (G, r)), don¬ 
de G denota los atributos de agrupamiento. Se omi¬ 
ten los detalles de la estimación de los valores distintos 
para otras operaciones. 


14.3. TRANSFORMACIÓN DE EXPRESIONES RELACIONALES 


Hasta ahora se han estudiado los algoritmos para eva¬ 
luar las operaciones extendidas del álgebra relacional y 
hacer estimaciones de sus costes. Como se mencionó al 
comienzo de este capítulo, las consultas se pueden expre¬ 
sar de varias maneras diferentes, con costes de evalua¬ 
ción diferentes. En este apartado, en lugar de tomar la 
expresión relacional como se da, se consideran expre¬ 
siones alternativas equivalentes. 

Se dice que dos expresiones del álgebra relacional 
son equivalentes si, en cada ejemplar legal de la base 
de datos, las dos expresiones generan el mismo conjun¬ 
to de tupias. (Recuérdese que un ejemplar legal de la 
base de datos es la que satisface todas las restricciones 
de integridad especificadas en el esquema de la base de 
datos.) Obsérvese que el orden de las tupias resulta irre¬ 
levante; puede que las dos expresiones generen las tupias 
en órdenes diferentes, pero se considerarán equivalen¬ 
tes siempre que el conjunto de tupias sea el mismo. 

En SQL las entradas y las salidas son multiconjun- 
tos de tupias, y se utiliza la versión para multiconjun- 
tos del álgebra relacional para evaluar las consultas de 
SQL. Se dice que dos expresiones de la versión para 
mu l tic o njuntos del álgebra relacional son equivalentes 
si en cada base de datos legal las dos expresiones gene¬ 
ran el mismo multiconjunto de tupias. El estudio de este 
capítulo se basa en el álgebra relacional. Las extensio¬ 
nes a la versión para multiconjuntos del álgebra rela¬ 
cional se dejan al lector como ejercicios. 

14.3.1. Reglas de equivalencia 

Una regla de equivalencia dice que las expresiones de 
dos formas son equivalentes. Se puede sustituir una 
expresión de la primera forma por una expresión de la 
segunda forma, o viceversa —es decir, se puede susti¬ 
tuir una expresión de la segunda forma por una expre¬ 
sión de la primera forma—, ya que las dos expresiones 
generan el mismo resultado en cualquier base de datos 
válida. El optimizador utiliza las reglas de equivalen¬ 
cia para transformar las expresiones en otras equiva¬ 
lentes lógicamente. 


A continuación se relacionan varias reglas generales 
de equivalencia para las expresiones del álgebra rela¬ 
cional. Algunas de las equivalencias relacionadas apa¬ 
recen en la Figura 14.2. Se utilizan 6, d u d 2 , etcétera, 
para denotar los predicados, L¡, L 2 , L 3 , etcétera, para 
denotar las listas de atributos y E, E lt E 2 , etcétera, para 
denotar las expresiones del álgebra relacional. El nom¬ 
bre de relación r no es más que un caso especial de 
expresión del álgebra relacional y puede utilizarse siem¬ 
pre que aparezca E. 

1. Las operaciones de selección conjuntivas pueden 
dividirse en una secuencia de selecciones indivi¬ 
duales. Esta transformación se denomina casca¬ 
da de o. 


¿Ve, (£) = Os, (Oe 2 (£)) 




X 



M 


El E2 


Regla 7a 
-► 

Si 0 sólo contiene 
atributos de El 



FIGURA 14.2. Representación gráfica de las equivalencias. 
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2. Las operaciones de selección son conmutativas. 

00, (Og 2 (E)) = Og 2 (a g¡ (£)) 

3. Sólo son necesarias las últimas operaciones de 
una secuencia de operaciones de proyección, las 
demás pueden omitirse. Esta transformación 
también puede denominarse cascada de II. 

n L| (n ¿ 2 (...(n ¿i (£))...)) = n Li (£) 

4. Las selecciones pueden combinarse con los pro¬ 
ductos cartesianos y con las reuniones zeta. 

a. o e ( E l x E 2 ) = E x x 0 E 2 

Esta expresión es precisamente la definición 
de la reunión zeta. 

b* 00, ^g 2 E 2 ) = E { tx]0,y\0 2 E 2 

5. Las operaciones de reunión zeta son conmutati¬ 
vas. 

£[ Ng E 2 = E 2 Xg £; 

Realmente, el orden de los atributos es diferen¬ 
te en el término de la derecha y en el de la 
izquierda, por lo que la equivalencia no se cum¬ 
ple si se tiene en cuenta el orden de los atribu¬ 
tos. Se puede añadir una operación de proyec¬ 
ción a uno de los lados de la equivalencia para 
reordenar los atributos de la manera adecuada, 
pero por simplicidad se omite la proyección y 
se ignora el orden de los atributos en la mayor 
parte de los ejemplos. 

Recuérdese que el operador de reunión natu¬ 
ral es simplemente un caso especial del opera¬ 
dor de reunión zeta; por tanto, las reuniones natu¬ 
rales también son conmutativas. 

6. a. Las operaciones de reunión natural son aso¬ 

ciativas. 

(£j IX E 2 ) X E 3 = £j IX (E 2 IX £ 3 ) 

b. Las reuniones zeta son asociativas en el sen¬ 
tido siguiente: 

(E l X 0[ £ 2 ) tXg,A0 3 ^3 = 

= Xg f A g 3 ( E 2 IX g 2 £ 3 ) 

donde d 2 implica solamente atributos de E 2 
y de £ 3 . Cualquiera de estas condiciones pue¬ 
de estar vacía; por tanto, se deduce que la 
operación producto cartesiano (x) también 
es asociativa. La conmutatividad y la aso- 
ciatividad de las operaciones de reunión son 
importantes para la reordenación de las reu¬ 
niones en la optimización de las consultas. 

7. La operación de selección se distribuye por la 
operación de reunión zeta bajo las dos condi¬ 
ciones siguientes: 


a. Se distribuye cuando todos los atributos de 
la condición de selección 6 0 implican única¬ 
mente los atributos de una de las expresiones 
(por ejemplo, £ 2 ) que se están reuniendo. 

°0 O C^j ^0 E 2 ) = (CTg o (£[)) tXg E 2 

b. Se distribuye cuando la condición de selec¬ 
ción 0 , implica únicamente los atributos de 
£[ y d 2 implica únicamente los atributos de 
£ 2 . 

°0, A 0, (¿j 1X@ ^ 2 ) = (00, C^l)) ^0 (00, (E 2 )) 

8 . La operación proyección se distribuye por la 
operación de reunión zeta bajo las condiciones 
siguientes. 

a. Sean £, y L 2 atributos de £, y de £ 2 , res¬ 
pectivamente. Supóngase que la condición 
de reunión 0 implica únicamente los atribu¬ 
tos de £[ U L 2 . Entonces, 

Ül, ul 2 C^l ^0 E 2 ) = 

= (n i ,(£ 1 )) tXg(n Í2 (£,)) 

b. Considérese una reunión £, x¡ e £ 2 . Sean L x 
y L 2 conjuntos de atributos de £, y de £ 2 , res¬ 
pectivamente. Sean £ 3 los atributos de £, que 
están implicados en la condición de reunión 
0 , pero que no están en £, U £ 2 , y sean £ 4 los 
atributos de £ 2 que están implicados en la 
condición de reunión 0, pero que no están en 
L[ U L 2 . Entonces, 

u¿ 2 (E\ ^0 e 2 ) = 

= u l 2 ((n¿, u l 3 (Ei)) w g (n L2 y (£ 2 ))) 

9. Las operaciones de conjuntos unión e intersec¬ 
ción son conmutativas. 

£,U £ 2 = £ 2 U£, 

£j n £ 2 = £ 2 n £j 

La diferencia de conjuntos no es conmutativa. 

10. La unión y la intersección de conjuntos son aso¬ 
ciativas. 

(£, U E 2 ) U £3 = £, U (£ 2 U £3) 

(£, n e 2 ) n £3 = £, n (£ 2 n £ 3 ) 

11. La operación de selección se distribuye por las 
operaciones de unión, intersección y diferencia 
de conjuntos. 

0 p (E\ ~ E 2 ) = o P (£,) — o P (£ 2 ) 

De manera parecida, la equivalencia anterior, con 
- sustituido por U o por D, también es válida. 
Además, 
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La equivalencia anterior, con - sustituido por fl, 
también es válida, pero no se cumple si - se sus¬ 
tituye por U. 

12. La operación de proyección se distribuye por la 
operación unión. 

W,. (£, U E 2 ) = (n, (£,)) U (TT,. (E 2 )) 

Ésta es sólo una lista parcial de las equivalencias. En 
los ejercicios se discuten más equivalencias que impli¬ 
can a los operadores relaciónales extendidos, como la 
reunión externa y la agregación. 

14.3.2. Ejemplos de transformaciones 

Ahora se ilustrará el empleo de las reglas de equiva¬ 
lencia. Se utilizará el ejemplo del banco con los esque¬ 
mas de relaciones: 

Esquema-sucursal = ( nombre-sucursal, 
ciudad-sucursal, activo) 

Esquema-cuenta = ( número-cuenta, 
nombre-sucursal, saldo) 

Esquema-impositor = (nombre-cliente, 
número-cuenta) 

Las relaciones sucursal, cuenta e impositor son ejem¬ 
plos de estos esquemas. 

En el ejemplo del Apartado 14.1 la expresión 

Wnombre-cliente ciudad-sucursal = «Arganzuela» 

(sucursal IX ( cuenta tx impositor))) 
se transformó en la expresión siguiente, 

0 nombre-cliente ciudad-sucursal = «Arganzuela» 

(sucursal)) tx (cuenta IX impositor)) 

que es equivalente a la expresión algebraica original, 
pero que genera relaciones intermedias de menor tama¬ 
ño. Esta transformación se puede llevar a cabo em¬ 
pleando la regla 7.a. Recuérdese que la regla sólo dice 
que las dos expresiones son equivalentes; no dice que 
una sea mejor que la otra. 

Se pueden utilizar varias reglas de equivalencia, una 
tras otra, sobre una consulta o sobre partes de una con¬ 
sulta. Como ejemplo, supóngase que se modifica la con¬ 
sulta original para restringir la atención a los clientes 
que tienen un saldo superior a 1.000 €. La nueva con¬ 
sulta del álgebra relacional es 

O nombre-cliente ciudad-sucursal =« Arganzuela» A saldo >1000 

(sucursal IX (cuenta ¡X impositor))) 

No se puede aplicar el predicado de la selección direc¬ 
tamente a la relación sucursal, ya que el predicado impli¬ 
ca atributos tanto de la relación sucursal como de la 
relación cuenta. No obstante, se puede aplicar antes la 


regla 6.a (asociatividad de la reunión natural) para trans¬ 
formar la reunión sucursal tx (cuenta tx impositor) en 
(sucursal IX cuenta) IX impositor. 

Wnombre-cliente ciudad-sucursal = «Arganzuela» A saldo >1000 

((sucursal tx cuenta) IX impositor)) 

Luego, empleando la regla 7.a, se puede reescribir la 
consulta como 

Él .nombre-cliente ((C ciudad-sucursal = «Arganzuela» A saldo 1000 

(sucursal IX cuenta)) tx impositor) 

Examinemos ahora la subexpresión de selección de esta 
expresión. Empleando la regla 1 se puede partir la selec¬ 
ción en dos, para obtener la subexpresión siguiente: 

Ociudad-sucursal = «Arganzuela» 

(°saido>\ooo (sucursal IX cuenta)) 

Las dos expresiones anteriores seleccionan tupias con 
ciudad-sucursal = «Arganzuela» y saldo > 1000. Sin 
embargo, la última forma de la expresión ofrece una 
nueva oportunidad de aplicar la regla «llevar a cabo pri¬ 
mero las selecciones», que da lugar a la subexpresión 

O ciudad-sucursal =«Arganzuela» (SUCUrSül) tX 
°saido> íooo (cuenta) 

La Figura 14.3 muestra la expresión inicial y la expre¬ 
sión final después de todas estas transformaciones. Tam¬ 
bién se podría haber utilizado la regla 7.b para obtener 
directamente la expresión final, sin utilizar la regla 1 
para partir la selección en dos selecciones. De hecho, 
la regla 7.b puede obtenerse de las reglas 1 y 7.a. 

Se dice que un conjunto de reglas de equivalencia es 
mínimo si no se puede obtener ninguna regla a partir 
de una reunión de las demás. El ejemplo anterior mues¬ 
tra que el conjunto de reglas de equivalencia del Apar¬ 
tado 14.3.1 no es mínimo. Se puede generar una expre¬ 
sión equivalente a la original de diferentes maneras; el 
número de maneras diferentes de generar una expresión 
aumenta cuando se utiliza un conjunto de reglas de equi¬ 
valencia que no es mínimo. Los optimizadores de con¬ 
sultas, por tanto, utilizan conjuntos mínimos de reglas 
de equivalencia. 

Considérese ahora la siguiente forma de la consulta 
de ejemplo: 

O nombre-cliente ((^ciudad -sucursal = «Arganzuela» 

(sucursal) IX cuenta) tx impositor) 

Cuando se calcula la subexpresión 

( ^ciudad-sucursal = «Arganzuela» (SUCUrSül) IX CUeilta) 

se obtiene una relación cuyo esquema es 

(nombre-sucursal, ciudad-sucursal, activo, 
número-cuenta, saldo) 
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I”! nombre-cliente 


1~[ nombre-cliente 


* ^ ciudad-sucursal = Arganzuela A saldo < 1000 


IX 



sucursal x 



cuenta Impositor 

(a) Árbol inicial de la expresión 
FIGURA 14.3. Varias transformaciones. 


IX 

1X1 ¡mpositor 

O ciudad-sucursal = Arganzuela ® saldos 1000 

sucursal cuenta 

(b) Árbol después de varias transformaciones 






Se pueden eliminar varios atributos del esquema, for¬ 
zando las proyecciones de acuerdo con las reglas de 
equivalencia 8.a y 8.b. Los únicos atributos que se deben 
conservar son los que aparecen en el resultado de la con¬ 
sulta y los que se necesitan para procesar las operacio¬ 
nes subsiguientes. Al eliminar los atributos innecesa¬ 
rios se reduce el número de columnas del resultado 
intermedio. Por tanto, se reduce el tamaño del resulta¬ 
do intermedio. En el ejemplo el único atributo que se 
necesita de la reunión de sucursal y de cuenta es núme¬ 
ro-cuenta. 

Por tanto, se puede modificar la expresión hasta 


0 nombre-cliente ( 

( YJniímero-cuenta ((^ ciudad-sucursal = «Arganzuela» ( SUCUCSal )) 

Xl cuenta )) XI impositor) 


La proyección I ^ m -n,ema reduce el tamaño de los resul¬ 
tados de las reuniones intermedias. 


14.3.3. Ordenación de las reuniones 

Una buena ordenación de las operaciones de reunión es 
importante para reducir el tamaño de los resultados tem¬ 
porales; por tanto, la mayor parte de los optimizadores 
de consultas prestan mucha atención al orden de las reu¬ 
niones. Como se mencionó en el Capítulo 3 y en la regla 
de equivalencia 6.a, la operación de reunión natural es 
asociativa. Por tanto, para todas las relaciones r t , r 2 y r 3 , 

(r l XI r 2 ) Xl r 3 = r, XI ( r 2 XI r 3 ) 

Aunque estas expresiones sean equivalentes, los costes 
de calcular cada una de ellas pueden ser diferentes. 
Considérese una vez más la expresión 


Se podría escoger calcular primero cuenta xi imposi¬ 
tor y luego combinar el resultado con 

Ociudad-sucursal = « Arganzuela» ( SUClirSUl) 

Sin embargo, es probable que cuenta IX impositor sea 
una relación de gran tamaño, ya que contiene una tupia 
por cada cuenta. Por el contrario, 

Ociudad-sucursal = «Arganzuela» ( SUCUrSül ) IX CUeilta 

es probablemente una relación de pequeño tamaño. Para 
comprobar que es así, se observa que, dado que el ban¬ 
co tiene un gran número de sucursales ampliamente dis¬ 
tribuidas, es probable que sólo una pequeña parte de los 
clientes del banco tenga cuenta en las sucursales ubi¬ 
cadas en Arganzuela. Por tanto, la expresión anterior da 
lugar a una tupia por cada cuenta abierta por un resi¬ 
dente de Arganzuela. Así, la relación temporal que se 
debe almacenar es menor que si se hubiera calculado 
primero cuenta XI impositor. 

Hay otras opciones a considerar a la hora de evaluar 
la consulta. No hay que preocuparse del orden en que 
aparecen los atributos en las reuniones, ya que resulta 
sencillo cambiarlo antes de mostrar el resultado. Por 
tanto, para todas las relaciones r { y r 2 , 

r { X r 2 = r 2 XI r l 

Es decir, la reunión natural es conmutativa (regla de 
equivalencia 5). 

Mediante la asociatividad y la conmutatividad de la 
reunión natural (reglas 5 y 6) se puede considerar rees¬ 
cribir la expresión del álgebra relacional como 


O nombre-cliente ciudad-sucursal = «Arganzuela» 

(sucursal)) XI cuenta IX impositor) 


i ~\nombre-cliente (((^ ciudad-sucursal = «Arganzuela» 

(sucursal)) IX impositor) Xl cuenta) 
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Es decir, se puede calcular primero 

( ®ciudad-sucursal = «Arganzuela» (sUCUrSül)) XI ¡mpOSÍtOY 

y, luego, reunir el resultado con cuenta. Obsérvese, no 
obstante, que no hay atributos en común entre Esque¬ 
ma-sucursal y Esquema-impositor, por lo que la reunión 
no es más que un producto cartesiano. Si hay o sucur¬ 
sales en Arganzuela e i tupias en la relación impositor, 
este producto cartesiano genera o * i tupias, una por cada 
par posible de tupias de impositor y de sucursal (inde¬ 
pendientemente de si la cuenta de impositor está abier¬ 
ta en la sucursal). Por tanto, parece que este producto 
cartesiano producirá una relación temporal de gran tama¬ 
ño. En consecuencia, esta estrategia se rechaza. No obs¬ 
tante, si el usuario ha introducido la expresión anterior, 
se pueden utilizar la asociatividad y la conmutatividad 
de la reunión natural para transformarla en la expresión 
más eficiente que se usó anteriormente. 

14.3.4. Enumeración de expresiones 
equivalentes 

Los optimizadores de consultas utilizan las reglas de 
equivalencia para generar de manera sistemática expre¬ 


siones equivalentes a la expresión de consulta dada. 
Conceptualmente el proceso se desarrolla de la mane¬ 
ra siguiente. Dada una expresión, si alguna subexpre¬ 
sión coincide con algún lado de una regla de equiva¬ 
lencia, el optimizador genera una nueva expresión en 
que la subexpresión se transforma para coincidir con el 
otro lado de la regla. Este proceso continúa hasta que 
no se puedan generar expresiones nuevas. 

El proceso anterior resulta costoso tanto en espacio 
como en tiempo. Este es el modo en que se puede redu¬ 
cir los requisitos de espacio: si se genera una expresión 
E l a partir de una expresión E 2 empleando una regla de 
equivalencia, E l y E 2 son parecidas en estructura y tienen 
subexpresiones que son idénticas. Las técnicas de repre¬ 
sentación de expresiones que permiten que las dos expre¬ 
siones apunten a las subexpresiones compartidas pueden 
reducir de manera significativa los requisitos de espacio, 
y muchos optimizadores de consultas las utilizan. 

Además, no siempre resulta necesario generar todas 
las expresiones que pueden generarse con las reglas de 
equivalencia. Si un optimizador tiene en cuenta las esti¬ 
maciones de costes, puede que logre evitar el examen 
de algunas de las expresiones, como se verá en el Apar¬ 
tado 14.4. Se puede reducir el tiempo necesario para la 
optimización empleando técnicas como éstas. 


14.4. ELECCIÓN DE LOS PLANES DE EVALUACIÓN 


La generación de expresiones sólo es una parte del pro¬ 
ceso de optimización de consultas, ya que cada opera¬ 
ción de la expresión puede implementarse con algorit¬ 
mos diferentes. Por tanto, se necesita un plan de 
evaluación para definir exactamente el algoritmo que 
se utilizará para cada operación y el modo en que se 
coordinará la ejecución de las operaciones. La Figura 
14.4 muestra un plan de evaluación posible para la 
expresión de la Figura 14.3. Como ya se ha visto, se 
pueden emplear varios algoritmos diferentes para cada 
operación relacional, lo que da lugar a planes de eva¬ 
luación alternativos. Además, hay que tomar decisiones 
sobre el encauzamiento. En la figura, los trazos de las 
operaciones de selección hasta la operación de reunión 
mezcla están marcados como encauzados; el encauza¬ 
miento es factible si las operaciones de selección gene¬ 
ran sus resultados ordenados según los atributos de reu¬ 
nión. Lo harán si los índices de sucursal y cuenta 
almacenan los registros con valores iguales de los atri¬ 
butos de índice ordenados por nombre-sucursal. 

14.4.1. Interacción de las técnicas 
de evaluación 

Una manera de escoger un plan de evaluación para una 
expresión de consulta es sencillamente escoger para 
cada operación el algoritmo más económico para eva¬ 


luarla. Se puede escoger cualquier ordenación de las 
operaciones que asegure que las operaciones ubicadas 
por debajo en el árbol se ejecuten antes que las opera¬ 
ciones situadas más arriba. 

Sin embargo, la selección del algoritmo más econó¬ 
mico para cada operación no es necesariamente una bue¬ 
na idea. Aunque puede que una reunión por mezcla en 
un nivel dado resulte más costosa que una reunión por 


I! nombre-cliente 

(ordenada para eliminar dupli¬ 
cados) 


X (reunión por asociación) 



sucursal cuenta 


FIGURA 14.4. Un plan de evaluación. 
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asociación, puede que proporcione un resultado orde¬ 
nado que haga más económica la evaluación de opera¬ 
ciones posteriores (como la eliminación de duplicados, 
la intersección u otra reunión por asociación). De mane¬ 
ra parecida, puede que una reunión en bucle anidado 
indexada proporcione oportunidades para el encauza- 
miento de los resultados de la operación siguiente y, por 
tanto, puede que resulte útil aunque no sea la manera 
más económica de llevar a cabo la reunión. Para esco¬ 
ger el mejor algoritmo global hay que considerar inclu¬ 
so los algoritmos no óptimos para operaciones indivi¬ 
duales. 

Por tanto, además de considerar las expresiones alter¬ 
nativas de cada consulta, también hay que considerar 
los algoritmos alternativos para cada operación de cada 
expresión. Se pueden utilizar reglas muy parecidas a las 
reglas de equivalencia para definir los algoritmos que 
pueden utilizarse para cada operación, y si su resultado 
puede encauzarse o se debe materializar. Se pueden uti¬ 
lizar estas reglas para generar todos los planes de eva¬ 
luación de consultas para una expresión dada. 

Dado un plan de evaluación, se puede estimar su cos¬ 
te empleando las estadísticas estimadas mediante las 
técnicas del Apartado 14.2 junto con las estimaciones 
de costes de varios algoritmos y métodos de evaluación 
descritos en el Capítulo 13. Eso sigue dejando el pro¬ 
blema de la selección del mejor plan de evaluación de 
la consulta. Hay dos enfoques generales: el primero bus¬ 
ca todos los planes y escoge el mejor de una manera 
basada en los costes. El segundo utiliza la heurística 
para escoger el plan. A continuación se estudiarán los 
dos enfoques. Los optimizadores de consultas prácticos 
incorporan elementos de ambos enfoques. 

14.4.2. Optimización basada en el coste 

Los optimizadores basados en el coste generan una 
gama de planes de evaluación a partir de la consulta 
dada empleando las reglas de equivalencia y escogen el 
de coste mínimo. Para las consultas complejas el núme¬ 
ro de planes de consulta diferentes que son equivalen¬ 
tes a un plan dado puede ser grande. A modo de ejem¬ 
plo, considérese la expresión 


r, IX r 2 X x r n 

en la que las reuniones se expresan sin ninguna orde¬ 
nación. Con n = 3, hay 12 diferentes ordenaciones de 
la mezcla: 


A 

¡XI 

( r 2 XI 

D) 

A 

XI 

(D 

X 

d) 

D 

XI 

(D XI 

d) 

r 2 

XI 

(a 

X 

r 1 ) 

D 

XI 

Oí Xl 

d) 

r 3 

Xl 

(D 

X 

D) 

(r 2 

Xl 

r 3 ) Xl 

A 

(d 

XI 

d) 

X 

r 1 

( r i 

XI 

r 3 ) X! 

r 2 

(r 3 

X 

r 1 ) 

X 

D 

( r i 

XI 

r 2 ) X 

r 3 

(d 

X 

r 1 ) 

X 

A 


En general, con n relaciones, hay (2 (n - 1))!/(« - 1)! 
órdenes de reunión diferentes. (Se deja el cálculo de esta 
expresión al lector en el Ejercicio 14.10.) Para las reu¬ 
niones que implican números pequeños de relaciones, 
este número resulta aceptable; por ejemplo, con n = 5, 
el número es 1680. Sin embargo, a medida que n se 
incrementa, este número crece rápidamente. Con n = 7, 
el número es 665.280; con n = 10, ¡el número es mayor 
de 17.600 millones! 

Afortunadamente, no es necesario generar todas las 
expresiones equivalentes a la expresión dada. Por ejem¬ 
plo, supóngase que se desea hallar el mejor orden de 
reunión de la forma 

(r, x r 2 IX r 3 ) Xl r 4 (X r 5 

que representa todos los órdenes de reunión en que r x , 
r 2 y r 3 se reúnen primero (en algún orden), y el resulta¬ 
do se reúne (en algún orden) con r 4 y r 5 . Hay doce órde¬ 
nes de reunión diferentes para calcular r { Xl r 2 X] r 3 , y 
otros doce órdenes para calcular la reunión de este resul¬ 
tado con r 4 y r 5 . Por tanto, parece que hay 144 órdenes 
de reunión que examinar. Sin embargo, una vez halla¬ 
do el mejor orden de reunión para el subconjunto de 
relaciones {r¡, r 2 , r 3 }, se puede utilizar ese orden para 
las reuniones posteriores con r 4 y r 5 , y se pueden igno¬ 
rar todos los órdenes de reunión más costosos de r { Xl 
r 2 XI r 3 . Por tanto, en lugar de 144 opciones que exa¬ 
minar sólo hace falta examinar 12+12 opciones. 


procedure hallarmejorplan(S) 
if (mejorplanlS],coste * °°) 
return mejorplanlS] 

¡f (S contiene sólo una relación) 

establecer mejorplanlS],plan y mejorplanlS],coste en términos de la mejor forma de acceder a S 
// mejorplanlS] no se ha calculado anteriormente, hay que calcularlo ahora 
else for each subconjunto no vacío SI de S tal que SI * S 
P1 = hallarmejorplan(SI) 

P2 = hallarmejorplanjS- SI) 

A = mejor algoritmo para reunir los resultados de P1 y P2 
coste = P],coste + P2.coste + coste de A 
¡f coste < mejorplanlS],coste 
mejorplanlS],coste = coste 

mejorplanlS],plan = «ejecutar Pt.plan; ejecutar P2.plan; reunir resultados de P1 y de P2 utilizando A » 
return mejorplanlS] 

FIGURA 14.5. Algoritmo de programación dinámica para la optimización del orden de reunión. 
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Utilizando esta idea se puede desarrollar un algorit¬ 
mo de programación dinámica para hallar los órdenes 
de reunión óptimos. Los algoritmos de programación 
dinámica almacenan los resultados de los cálculos y los 
reutilizan, un procedimiento que puede reducir enor¬ 
memente el tiempo de ejecución. En la Figura 14.5 apa¬ 
rece un procedimiento recursivo que implementa el algo¬ 
ritmo de programación dinámica. 

El procedimiento almacena los planes de evaluación 
que calcula en el array asociado mejorplan, que está 
indexado por conjuntos de relaciones. Cada elemento 
del array asociativo contiene dos componentes: el cos¬ 
te del mejor plan de S y el propio plan. El valor de mejor- 
plan[S].coste se supone que se inicializa como 00 si 
mejorplan[S ] no se ha calculado todavía. 

El procedimiento comprueba en primer lugar si el 
mejor plan para calcular la reunión del conjunto de rela¬ 
ciones dado S se ha calculado ya (y se ha almacenado en 
el array asociativa mejorplan)', si es así, devuelve el plan 
ya calculado. Si S sólo contiene una relación, se calcula 
la mejor forma de acceder a S (teniendo en cuenta las 
relaciones sobre S, si las hay) y se almacena en mejor¬ 
plan. En caso contrario, el procedimiento intenta todas 
las maneras posibles de dividir S en dos subconjuntos 
disjuntos. Para cada división el procedimiento halla de 
manera recursiva los mejores planes para cada uno de los 
dos subconjuntos y luego calcula el coste del plan global 
utilizando esa división. El procedimiento escoge el plan 
más económico de entre todas las alternativas para divi¬ 
dir S en dos conjuntos. El procedimiento almacena el plan 
más económico y su coste en el array mejorplan y los 
devuelve. La complejidad temporal del procedimiento 
puede demostrarse que es 0(3") (véase el Ejercicio 14.11). 

En realidad, el orden en que la reunión de un conjunto 
de relaciones genera las tupias también es importante 
para hallar el mejor orden global de reunión, ya que pue¬ 
de afectar al coste de las reuniones posteriores (por ejem¬ 
plo, si se utiliza una mezcla). Se dice que un orden deter¬ 
minado de las tupias es un orden interesante si puede 
resultar útil para alguna operación posterior. Por ejem¬ 
plo, la generación del resultado de r, fcl r 2 XI r 3 ordena¬ 
do según los atributos comunes con r 4 o r 5 puede resul¬ 
tar útil, pero generarlo ordenado según los atributos 
comunes solamente con r i y r 2 no resulta útil. El empleo 
de la reunión por mezcla para calcular r l M r 2 txi r 3 pue¬ 
de resultar más costoso que emplear algún otro tipo de 
técnica de reunión, pero puede que proporcione un resul¬ 
tado ordenado según un orden interesante. 

Por tanto, no basta con hallar el mejor orden de reu¬ 
nión para cada subconjunto del conjunto de n relaciones 
dadas. Por el contrario, hay que hallar el mejor orden de 
reunión para cada subconjunto para cada orden intere¬ 
sante de la reunión resultante para ese subconjunto. El 
número de subconjuntos de n relaciones es 2 n . El núme¬ 
ro de órdenes de colocación interesantes no suele ser gran¬ 
de. Así, hay que almacenar alrededor de 2" expresiones 
de reunión. El algoritmo de programación dinámica para 
hallar el mejor orden de reunión puede extenderse de 


manera sencilla para que trabaje con los órdenes de colo¬ 
cación. El coste del algoritmo extendido depende del 
número de órdenes interesantes para cada subconjunto 
de relaciones; dado que se ha hallado que este número 
en la práctica es pequeño, el coste se queda en 0(3''). 

Con n = 10 este número es de alrededor de 59.000, 
que es mucho mejor que los 17.600 millones de órde¬ 
nes de reunión diferentes. Y lo que es más importante, 
el almacenamiento necesario es mucho menor que antes, 
ya que sólo hace falta almacenar un orden de reunión 
por cada orden interesante de cada uno de los 1.024 sub¬ 
conjuntos de r,,_r 10 . Aunque los dos números siguen 

creciendo rápidamente con n, las reuniones que se pro¬ 
ducen con frecuencia suelen tener menos de diez rela¬ 
ciones y pueden manejarse con facilidad. 

Se pueden utilizar varias técnicas para reducir aún 
más el coste de la búsqueda entre un gran número de 
planes. Por ejemplo, al examinar los planes para una 
expresión se puede concluir tras examinar sólo una par¬ 
te de la expresión si se determina que el plan más eco¬ 
nómico para esa parte ya resulta más costoso que el plan 
de evaluación más económico para una expresión com¬ 
pleta examinada anteriormente. De manera parecida, 
supóngase que se determina que la manera más econó¬ 
mica de evaluar una subexpresión es más costosa que 
el plan de evaluación más económico para una expre¬ 
sión completa examinada anteriormente. Entonces, no 
hace falta examinar ninguna expresión completa que 
incluya esa subexpresión. Se puede reducir aún más el 
número de planes de evaluación que hay que conside¬ 
rar completamente llevando a cabo antes una selección 
heurística de un buen plan y estimando el coste de ese 
plan. Luego, sólo unos pocos planes competidores nece¬ 
sitarán un análisis completo de los costes. Estas opti¬ 
mizaciones pueden reducir de manera significativa la 
sobrecarga de la optimización de consultas. 

14.4.3. Optimización heurística 

Un inconveniente de la optimización basada en el cos¬ 
te es el coste de la propia optimización. Aunque el cos¬ 
te del procesamiento de las consultas puede reducirse 
mediante optimizaciones inteligentes, la optimización 
basada en el coste sigue resultando costosa. Por ello, 
muchos sistemas utilizan la heurística para reducir el 
número de elecciones que hay que hacer de una mane¬ 
ra basada en los costes. Algunos sistemas incluso deci¬ 
den utilizar sólo la heurística y no utilizan en absoluto 
la optimización basada en el coste. 

Un ejemplo de regla heurística es la siguiente regla 
para la transformación de consultas del álgebra rela- 
cional: 

• Llevar a cabo las operaciones de selección tan 
pronto como sea posible. 

Los optimizadores heurísticos utilizan esta regla sin ave¬ 
riguar si se reduce el coste mediante esta transformación. 
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En el primer ejemplo de transformación del Apartado 
14.3 se forzó la operación de selección en una reunión. 

Se dice que la regla anterior es heurística porque sue¬ 
le ayudar a reducir el coste, aunque no lo haga siempre. 
Como ejemplo de dónde puede dar lugar a un incre¬ 
mento del coste, considérese una expresión o g (r Xl s), 
donde la condición 6 sólo hace referencia a atributos de 
5. Ciertamente, la selección puede llevarse a cabo antes 
de la reunión. Sin embargo, si r es tremendamente 
pequeña comparada con s, y si hay un índice basado en 
los atributos de reunión de s pero no hay ningún índice 
basado en los atributos utilizados por 6, probablemen¬ 
te resulte una mala idea llevar a cabo la selección pron¬ 
to. Llevar a cabo pronto la selección —es decir, direc¬ 
tamente sobre 5— exigiría hacer una exploración de 
todas las tupias de 5. Probablemente resulte más eco¬ 
nómico calcular la reunión utilizando el índice y luego 
rechazar las tupias que no superen la selección. 

La operación de proyección, como la operación de 
selección, reduce el tamaño de las relaciones. Por tan¬ 
to, siempre que haya que generar una relación tempo¬ 
ral, resulta ventajoso aplicar inmediatamente cuantas 
proyecciones sea posible. Esta ventaja sugiere un acom¬ 
pañante a la heurística «llevar a cabo las selecciones tan 
pronto como sea posible»: 

• Llevar a cabo las proyecciones tan pronto como 
sea posible. 

Suele resultar mejor llevar a cabo las selecciones antes 
que las proyecciones, ya que las selecciones tienen la 
posibilidad de reducir mucho el tamaño de las relacio¬ 
nes y permiten el empleo de índices para tener acceso 
a las tupias. Un ejemplo parecido al utilizado para la 
heurística de selección debería convencer al lector de 
que esta heurística no siempre reduce el coste. 

Aprovechando las equivalencias estudiadas en el 
Apartado 14.3.1, un algoritmo de optimización heurís¬ 
tica reordenará los componentes de un árbol de consul¬ 
tas inicial para conseguir una ejecución mejorada de la 
consulta. A continuación se presenta una visión gene¬ 
ral de las etapas de un algoritmo típico de optimización 
heurística. El lector comprenderá la heurística al visua¬ 
lizar la expresión de la consulta como si fuera un árbol, 
como se muestra en la Ligura 14.3. 

1. Hay que descomponer las selecciones conjunti¬ 
vas en una secuencia de operaciones de selección 
sencillas. Este paso, basado en la regla de equi¬ 
valencia 1, facilita el desplazamiento de las ope¬ 
raciones de selección hacia la parte inferior del 
árbol de consultas. 

2. Hay que desplazar las operaciones de selección 
hacia la parte inferior del árbol de consultas para 
conseguir su ejecución lo antes posible. Este paso 
utiliza las propiedades de conmutatividad y de 
distributividad de la operación de selección pues¬ 
tas de manifiesto en las reglas de equivalencia 2, 
7.a,7.by 11. 


Por ejemplo, este paso transforma o g (r ixi s) 
en o g (r) XI 5 o en r Xl o g ( 5 ) siempre que sea 
posible. La realización de las selecciones basa¬ 
das en valores tan pronto como sea posible redu¬ 
ce el coste de ordenación y de mezcla de los resul¬ 
tados intermedios. El grado de reordenación 
permitido para una selección concreta viene deter¬ 
minado por los atributos implicados en esa con¬ 
dición de selección. 

3. Hay que determinar las operaciones de selección 
y de reunión que producirán las relaciones de 
menor tamaño, es decir, que producirán las rela¬ 
ciones con el menor número de tupias. Utilizan¬ 
do la asociatividad de la operación hay que reor¬ 
denar el árbol para que las relaciones de los nodos 
hojas con esas selecciones restrictivas se ejecu¬ 
ten antes. 

Este paso considera la selectividad de las con¬ 
diciones de selección o de reunión. Hay que recor¬ 
dar que la selección más restrictiva —es decir, la 
condición con la selectividad de menor tamaño— 
recupera el menor número de registros. Este paso 
confía en la asociatividad de las operaciones bina¬ 
rias dada en la regla de equivalencia 6. 

4. Hay que sustituir por operaciones de reunión las 
operaciones producto cartesiano seguidas de con¬ 
diciones de selección (regla 4.a). La operación 
producto cartesiano suele resultar costosa de 
implementar, ya que r { x r 2 incluye un registro 
por cada combinación de registros procedentes 
de r { y de r 2 . La selección puede reducir de mane¬ 
ra significativa el número de registros, haciendo 
la reunión mucho menos costosa que el produc¬ 
to cartesiano. 

5. Hay que dividir las listas de atributos de proyec¬ 
ción y desplazarlas hacia la parte inferior del árbol 
todo lo que sea posible, creando proyecciones 
nuevas donde sea necesario. Este paso se apro¬ 
vecha de las propiedades de la operación de pro¬ 
yección dadas en las reglas de equivalencia 3, 8.a, 
8.by 12. 

6 . Hay que identificar los subárboles cuyas opera¬ 
ciones pueden encauzarse y ejecutarlos utilizan¬ 
do el encauzamiento. 

En resumen, las heurísticas citadas aquí reordenan 
la representación inicial del árbol de consultas de mane¬ 
ra que las operaciones que reducen el tamaño de los 
resultados intermedios se apliquen antes; las seleccio¬ 
nes tempranas reducen el número de tupias y las pro¬ 
yecciones tempranas reducen el número de atributos. 
Las transformaciones heurísticas también reestructuran 
el árbol de modo que el sistema lleve a cabo las opera¬ 
ciones de selección y de reunión más restrictivas antes 
que otras operaciones parecidas. 

La optimización heurística hace corresponder aún 
más la expresión de consulta transformada heurística- 
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mente con secuencias alternativas de operaciones para 
producir un conjunto candidato de planes de evaluación. 
Cada plan de evaluación no sólo incluye las operacio¬ 
nes relaciónales que hay que llevar a cabo, sino tam¬ 
bién los índices que hay que emplear, el orden en el que 
hay que tener acceso a las tupias y el orden en que hay 
que realizar las operaciones. La fase de selección del 
plan de acceso del optimizador heurístico selecciona 
la estrategia más eficiente para cada operación. 

14.4.4. Estructura de los optimizadores 
de consultas ** 

Hasta ahora se han descrito dos enfoques básicos de la 
selección de planes de evaluación; como se ha indica¬ 
do, los optimizadores de consultas más prácticos com¬ 
binan elementos de ambos enfoques. Por ejemplo, algu¬ 
nos optimizadores de consultas, como el optimizador 
System R, no toman en consideración todos los órde¬ 
nes de reunión, sino que restringen la búsqueda a tipos 
concretos de órdenes de reunión. El optimizador Sys¬ 
tem R sólo toma en consideración los órdenes de reu¬ 
nión en que el operando de la derecha de cada reunión 
es una de las relaciones iniciales r x , , r n . Estos órde¬ 
nes de reunión se denominan órdenes de reunión en 
profundidad por la izquierda. Los órdenes de reunión 
en profundidad por la izquierda resultan especialmen¬ 
te convenientes para la evaluación encauzada, ya que 
el operando de la derecha es una relación almacenada 
y, así, sólo se encauza una entrada por cada reunión. 

La Figura 14.6 muestra la diferencia entre un árbol 
de reunión en profundidad por la izquierda y otro que 
no lo es. El tiempo que se tarda en tomar en considera¬ 
ción todos los órdenes de reunión en profundidad por 
la izquierda es 0(n\), que es mucho menor que el tiem¬ 
po necesario para tomar en consideración todos los órde¬ 
nes de reunión. Con el empleo de las optimizaciones de 
programación dinámica, el optimizador de System R 
puede hallar el mejor orden de reunión en un tiempo de 
0(n2"). Compárese este coste con el tiempo de 0(3") 
necesario para hallar el mejor orden de reunión global. 
El optimizador System R utiliza la heurística para for- 



(a) Árbol de reunión 
en profundidad 
por la izquierda 


(b) Árbol de reunión 
que no es en profundidad 
por la izquierda 


FIGURA 14.6. Árboles de reunión. 


zar el desplazamiento de las selecciones y de las pro¬ 
yecciones hacia la parte inferior del árbol de consultas. 

La estimación de costes que se presentó para la explo¬ 
ración mediante índices secundarios daba por supuesto 
que cada acceso a una tupia da lugar a una operación 
de E/S. Es probable que la estimación resulte precisa 
con memorias intermedias de pequeño tamaño; con 
memorias intermedias de gran tamaño, sin embargo, 
puede que la página que contiene la tupia esté ya en la 
memoria intermedia. Algunos optimizadores incorpo¬ 
ran una técnica mejor de estimación de costes para estas 
exploraciones: tienen en cuenta la probabilidad de que 
la página que contiene la tupia se halle en el memoria 
intermedia. 

Los enfoques de la optimización de consultas que 
integran la selección heurística y la generación de pla¬ 
nes de acceso alternativos se han adoptado en varios sis¬ 
temas. El enfoque utilizado en System R y en su suce¬ 
sor, el proyecto Starburst, es un procedimiento jerárquico 
basado en el concepto de bloques anidados de SQL. Las 
técnicas de optimización basadas en costes aquí des¬ 
critas se utilizan por separado para cada bloque de la 
consulta. 

El enfoque heurístico de algunas versiones de Ora¬ 
cle funciona aproximadamente de esta manera: para 
cada reunión de grado n toma en consideración n pla¬ 
nes de evaluación. Cada plan utiliza un orden de reu¬ 
nión en profundidad por la izquierda, comenzando con 
una relación diferente de las n existentes. La heurística 
crea el orden de reunión para cada uno de los n planes 
de evaluación seleccionando de manera repetida la 
«mejor» relación que reunir a continuación, con base 
en la clasificación de los caminos de acceso disponi¬ 
bles. Se escoge la reunión en bucle anidado o mezcla- 
ordenación para cada una de las reuniones, en función 
de los caminos de acceso disponibles. Finalmente, la 
heurística escoge uno de los n planes de evaluación de 
manera heurística, basada en la minimización del núme¬ 
ro de reuniones de bucle anidado que no tienen dispo¬ 
nible un índice para la relación intema y en el número 
de reuniones por mezcla-ordenación. 

La complejidad de SQL introduce un elevado grado 
de complejidad en los optimizadores de consultas. En 
concreto, resulta difícil traducir las subconsultas ani¬ 
dadas de SQL al álgebra relacional. Se describirá bre¬ 
vemente el modo de tratar las subconsultas anidadas en 
el Apartado 14.4.5. Para las consultas compuestas de 
SQL (que utilizan la operación U, H o -), el optimiza¬ 
dor procesa cada componente por separado y combina 
los planes de evaluación para formar el plan global de 
evaluación. 

Incluso con el uso de la heurística la optimización 
de consultas basada en los costes impone una sobre¬ 
carga sustancial al procesamiento de las consultas. No 
obstante, el coste añadido de la optimización de las 
consultas basada en los costes suele compensarse con 
creces por el ahorro en tiempo de ejecución de la con¬ 
sulta, que queda dominado por los accesos lentos a los 
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discos. La diferencia en el tiempo de ejecución entre 
un buen plan y uno malo puede ser enorme, lo que 
vuelve esencial la optimización de las consultas. El 
ahorro conseguido se multiplica en las aplicaciones 
que se ejecutan de manera regular, en las que se pue¬ 
de optimizar la consulta una sola vez y utilizarse el 
plan de consultas seleccionado en cada ejecución. Por 
tanto, la mayor parte de los sistemas comerciales inclu¬ 
yen optimizadores relativamente sofisticados. Las notas 
bibliográficas dan referencias de las descripciones de 
los optimizadores de consultas de los sistemas de bases 
de datos reales. 

14.4.5. Optimización de las subconsultas 
anidadas** 

SQL trata conceptualmente a las subconsultas anidadas 
de la cláusula where como funciones que toman pará¬ 
metros y devuelven un solo valor o un conjunto de valo¬ 
res (quizás, un conjunto vacío). Los parámetros son las 
variables de la consulta del nivel externo que se utili¬ 
zan en la subconsulta anidada (estas variables se deno¬ 
minan variables de correlación). Por ejemplo, supón¬ 
gase que se tiene la consulta siguiente. 

select nombre-cliente 

from prestatario 

where exists (select * 

from impositor 

where impositor.nombre-cliente = 

= prestatario.nombre-cliente) 

Conceptualmente, la subconsulta puede considerarse 
como una función que toma un parámetro (aquí, pres¬ 
tatario.nombre-cliente) y devuelve el conjunto de todos 
los impositores con el mismo nombre. 

SQL evalúa la consulta global (conceptualmente) 
calculando el producto cartesiano de las relaciones de 
la cláusula from externa y comprobando luego los pre¬ 
dicados de la cláusula where para cada tupia del pro¬ 
ducto. En el ejemplo anterior, el predicado comprueba 
si el resultado de la evaluación de la subconsulta está 
vacío. 

Esta técnica para evaluar una consulta con una sub¬ 
consulta anidada se denomina evaluación correlacio¬ 
nada. La evaluación correlacionada no resulta muy efi¬ 
ciente, ya que la subconsulta se evalúa por separado 
para cada tupia de la consulta del nivel externo. Puede 
dar lugar a gran número de operaciones aleatorias de 
E/S a disco. 

Por tanto, los optimizadores de SQL intentan trans¬ 
formar las subconsultas anidadas en reuniones, siempre 
que resulta posible. Los algoritmos de reunión eficien¬ 
tes evitan las costosas operaciones aleatorias de E/S. 
Cuando la transformación no resulta posible el optimi- 
zador conserva las subconsultas como expresiones inde¬ 
pendientes, las optimiza por separado y luego las eva¬ 
lúa mediante la evaluación correlacionada. 


Como ejemplo de transformación de una subconsulta 
anidada en una reunión, la consulta del ejemplo ante¬ 
rior puede reescribirse como: 

select nombre-cliente 
from prestatario, impositor 
where impositor.nombre-cliente = 

= prestatario.nombre-cliente 

(Para reflejar correctamente la semántica de SQL no 
debe cambiar el número de derivaciones duplicadas 
debido a la reescritura; la consulta reescrita puede modi¬ 
ficarse para asegurarse de que se cumple esta propie¬ 
dad, como se verá en breve.) 

En el ejemplo la subconsulta anidada era muy sen¬ 
cilla. En general, puede que no resulte posible despla¬ 
zarlas relaciones de la subconsulta anidada a la cláusu¬ 
la from de la consulta externa. En lugar de eso, se crea 
una relación temporal que contiene el resultado de la 
consulta anidada sin las selecciones empleando las varia¬ 
bles de correlación de la consulta externa y se reúne la 
tabla temporal con la consulta del nivel exterior. Por 
ejemplo, una consulta de la forma 

select... 

from L¡ 

where P { and exists (select * 
from L 2 
where P 2 ) 

donde P 2 es una conjunción de predicados más senci¬ 
llos, puede reescribirse como 

create table t l as 
select distinct V 
from L 2 
where P\ 

select... 
from Lj, t\ 
where P¡ and P\ 

donde P 2 contiene los predicados de P 2 sin las selec¬ 
ciones que implican las variables de correlación, y Pl 
reintroduce las selecciones que implican las variables 
de correlación (con las relaciones a que se hace refe¬ 
rencia en el predicado renombradas adecuadamente). 
Aquí V contiene todos los atributos que se utilizan en 
las selecciones con las variables de correlación en la 
subconsulta anidada. 

En el ejemplo la consulta original se habría trans¬ 
formado en 

create table t ] as 

select distinct nombre-cliente 
from impositor 
select nombre-cliente 
from prestatario, t, 

where í, .nombre-cliente = prestatario.nombre-cliente 
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La consulta que se reescribió para mostrar la creación 
de relaciones temporales puede obtenerse simplificando 
la consulta transformada más arriba, suponiendo que el 
número de duplicados de cada tupia no importa. 

El proceso de sustituir una consulta anidada por una 
consulta con una reunión (acaso con una relación tem¬ 
poral) se denomina descorrelación. 

La descorrelación resulta más complicada cuando la 
subconsulta anidada utiliza la agregación o cuando el 
resultado de la subconsulta anidada se utiliza para com¬ 
probar la igualdad, o cuando la condición que enlaza la 
subconsulta anidada con la consulta exterior es not 


exists, etcétera. No se intentará dar algoritmos para el 
caso general y, en vez de eso, se remitirá al lector a los 
elementos de importancia en las notas bibliográficas. 

La optimización de las subconsultas anidadas com¬ 
plejas es una labor difícil, como puede deducirse del 
estudio anterior, y muchos optimizadores sólo llevan a 
cabo una cantidad limitada de descorrelación. Resulta 
más conveniente evitar el empleo de subconsultas ani¬ 
dadas complejas, siempre que sea posible, ya que no se 
puede asegurar que el optimizador de consultas tenga 
éxito en su conversión a una forma que pueda evaluar¬ 
se de manera eficiente. 


14.5. VISTAS MATERIALIZADAS** 


Cuando se define una vista, normalmente la base de 
datos sólo almacena la consulta que define la vista. Por 
el contrario, una vista materializada es una vista cuyo 
contenido se calcula y se almacena. Las vistas materia¬ 
lizadas constituyen datos redundantes, en el sentido de 
que su contenido puede deducirse de la definición de la 
vista y del resto del contenido de la base de datos. No 
obstante, resulta mucho más económico en muchos 
casos leer el contenido de una vista materializada que 
calcular el contenido de la vista ejecutando la consulta 
que la define. 

Las vistas materializadas resultan importantes para 
la mejora del rendimiento de algunas aplicaciones. Con¬ 
sidérese esta vista, que da el importe total de los prés¬ 
tamos de cada sucursal: 

create view total-préstamos-sucursal 

(nombre-sucursal, total-préstamos) as 
select nombre-sucursal, sum (importe) 
from préstamos 
groupby nombre-sucursal 

Supóngase que el importe total de los préstamos de la 
sucursal se solicita con frecuencia (antes de conceder 
un nuevo préstamo, por ejemplo). El cálculo de la vis¬ 
ta exige la lectura de cada tupia de préstamos corres¬ 
pondiente a la sucursal y sumar los importes de los prés¬ 
tamos, lo que puede ocupar mucho tiempo. Por el 
contrario, si la definición de la vista del importe total 
de los préstamos estuviera materializada, el importe total 
de los préstamos podría hallarse buscando una sola tupia 
de la vista materializada. 

14.5.1. Mantenimiento de las vistas 

Un problema con las vistas materializadas es que hay 
que mantenerlas actualizadas cuando se modifican los 
datos empleados en la definición de la vista. Por ejem¬ 
plo, si se actualiza el valor importe de un préstamo, la 
vista materializada se vuelve inconsistente con los datos 


subyacentes y hay que actualizarla. La tarea de mante¬ 
ner actualizada una vista materializada con los datos 
subyacentes se denomina mantenimiento de la vista. 

Las vistas pueden mantenerse mediante código escri¬ 
to a mano: es decir, cada fragmento del código que 
actualiza el valor importe del préstamo puede modifi¬ 
carse para actualizar el importe total de los préstamos 
de la sucursal correspondiente. 

Otra opción para el mantenimiento de las vistas mate¬ 
rializadas es la definición de desencadenadores para la 
inserción, la eliminación y la actualización de cada rela¬ 
ción de la definición de la vista. Los desencadenadores 
deben modificar el contenido de la vista materializada 
para tener en cuenta el cambio que ha provocado que 
se active el desencadenador. Una manera simplista de 
hacerlo es volver a calcular completamente la vista mate¬ 
rializada con cada actualización. 

Una opción mejor es modificar sólo las partes afec¬ 
tadas de la vista materializada, lo que se conoce como 
mantenimiento incremental de la vista. En el Apar¬ 
tado 14.5.2 se describe la manera de llevar a cabo el 
mantenimiento incremental de la vista. 

Los sistemas modernos de bases de datos propor¬ 
cionan más soporte directo para el mantenimiento incre¬ 
mental de las vistas. Los programadores de bases de 
datos ya no necesitan definir desencadenadores para el 
mantenimiento de las vistas. Por el contrario, una vez 
que se ha declarado materializada una vista, el sistema 
de bases de datos calcula su contenido y actualiza de 
manera incremental el contenido cuando se modifican 
los datos subyacentes. 

14.5.2. Mantenimiento incremental 
de las vistas 

Para comprender el modo de mantener de manera incre¬ 
mental las vistas materializadas se comenzará por con¬ 
siderar las operaciones individuales y luego se verá la 
manera de manejar una expresión completa. Los cam¬ 
bios de cada relación que puedan hacer que se quede 
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desactualizada una vista materializada son las insercio¬ 
nes, las eliminaciones y las actualizaciones. Para sim¬ 
plificar la descripción se sustituyen las actualizaciones 
a cada tupia por la eliminación de esa tupia seguida de 
la inserción de la tupia actualizada. Por tanto, sólo hay 
que considerar las inserciones y las eliminaciones. Los 
cambios (inserciones y eliminaciones) en la relación o 
en la expresión se denominan su diferencial. 

14.5.2.1. La operación reunión 

Considérese la vista materializada v = r ix 5. Supóngase 
que se modifica r insertando un conjunto de tupias deno¬ 
tado por i r Si el valor antiguo de r se denota por r v,ej " y 
el valor nuevo de r por r meva , r nueva = r VKj " U i r Ahora bien, 
el valor antiguo de la vista, v Víeja viene dado por r v,eja ix s, 
y el valor nuevo v" uer “ viene dado por r nueva XI s. Se puede 
reescribir r' meva X s como (r lw/ " U i r ) XI s, lo que se pue¬ 
de reescribir una vez más como (r neJa x s) U (i r x 1 s). 
En otros términos, 

v nuem = v vieja U (i r X s) 

Por tanto, para actualizar la vista materializada v, sólo 
hace falta añadir las tupias i r X 5 al contenido antiguo 
de la vista materializada. Las inserciones en 5 se mane¬ 
jan de una manera completamente simétrica. 

Supóngase ahora que se modifica r eliminando un 
conjunto de tupias denotado por d r Utilizando el mis¬ 
mo razonamiento que anteriormente se obtiene 

v nue Va = yVieja _ ^ ^ 

Las eliminaciones en 5 se manejan de una manera com¬ 
pletamente simétrica. 

14.5.2.2. Las operaciones selección 
y proyección 

Considérese una vista v = o g ( r ). Si se modifica r inser¬ 
tando un conjunto de tupias i r , el valor nuevo de v pue¬ 
de calcularse como 

V nuev a = v vieja \J 0g (Q 

De manera parecida, si se modifica r eliminando un con¬ 
junto de tupias e r , el valor nuevo de v puede calcularse 
como 

V nueva = V v ieja - O e ( e r) 

La proyección es una operación más difícil de tratar. 
Hay que considerar una vista materializada v = n A (r). 
Supóngase que la relación r está en el esquema R = (A, 
B) y que r contiene dos tupias, (a, 2) y (a, 3). Entonces, 
n A (r) tiene una sola tupia, ( a ). Si se elimina la tupia (a, 
2 ) de r, no se puede eliminar la tupia (a) de n A (r): si 
se hiciera, el resultado sería una relación vacía, mien¬ 
tras que en realidad n A (r) sigue teniendo una tupia (a). 


El motivo es que la misma tupia (a) se obtiene de dos 
maneras, y que la eliminación de una tupia de r sólo eli¬ 
mina una de las formas de obtener (a)\ la otra sigue pre¬ 
sente. 

Este motivo también ofrece una pista de la solución: 
para cada tupia de una proyección como n A (r), se lle¬ 
va la cuenta del número de veces que se ha obtenido. 

Cuando se elimina un conjunto de tupias e r de r, para 
cada tupia t de e r hay que hacer lo siguiente. 

t.A denota la proyección de t sobre el atributo A. Se 
busca (t.A) en la vista materializada y se disminuye la 
cuenta almacenada con ella en 1. Si la cuenta llega a 0, 
se elimina (t.A) de la vista materializada. 

El manejo de las inserciones resulta relativamente 
directo. Cuando un conjunto de tupias i r se inserta en r, 
para cada tupia t de i r se hace lo siguiente. Si (t.A) ya 
está presente en la vista materializada, se incrementa la 
cuenta almacenada con ella en 1. En caso contrario, se 
añade (t.A) a la vista materializada con la cuenta defi¬ 
nida como 1. 

14.5.2.3. Las operaciones de agregación 

Las operaciones de agregación se comportan aproxi¬ 
madamente como las proyecciones. Las operaciones de 
agregación en SQL son count, sum, avg, min y max: 

• count: Considérese una vista materializada 
v = aQ rueniaíH) (Q, que calcula la cuenta del atribu¬ 
to B , después de agrupar r según el atributo A. 

Cuando se inserta un conjunto de tupias i r en 
r, para cada tupia t de i r hay que hacer lo siguien¬ 
te. Se busca el grupo t.A en la vista materializa¬ 
da. Si no se halla presente, se añade (t.A, 1) a la 
vista materializada. Si el grupo t.A se halla pre¬ 
sente, se añade 1 a su cuenta. 

Cuando un conjunto e r se elimina de r, para cada 
tupia t de e r se hace lo siguiente. Se busca el gru¬ 
po t.A en la vista materializada y se resta 1 de la 
cuenta del grupo. Si la cuenta se hace 0, se elimi¬ 
na la tupia para el grupo t.A de la vista materiali¬ 
zada. 

• sum: Considérese una vista materializada v = 

= fSsum(B) 0')- 

Cuando un conjunto de tupias i r se inserta en 
r, para cada tupia t de i r se hace lo siguiente. Se 
busca el grupo t.A en la vista materializada. Si no 
se halla presente se añade (t.A, t.B) a la vista mate¬ 
rializada; además, se almacena una cuenta de 1 
asociada con (t.A, t.B), igual que se hizo para las 
proyecciones. Si el grupo t.A se halla presente, se 
añade el valor de t.B al valor agregado para el gru¬ 
po y se añade 1 a la cuenta del grupo. 

Cuando se elimina un conjunto de tupias er de 
r, para cada tupia t de er hay que hacer lo siguien¬ 
te. Se busca el grupo t.A en la vista materializa¬ 
da y se resta t.B del valor agregado para el gru¬ 
po. También se resta 1 de la cuenta del grupo y, 
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si la cuenta llega a 0, se elimina la tupia para el 
grupo t.A de la vista materializada. 

Si no se guardara el valor de cuenta adicional 
no se podría distinguir el caso de que la suma para 
el grupo sea 0 del caso en que se ha eliminado la 
última tupia de un grupo. 

• avg: Considérese una vista materializada v = A Q avgiF¡) 

O)- 

La actualización directa del promedio de una 
inserción o de una eliminación no resulta posible, 
ya que no sólo depende del promedio antiguo y de 
la tupia que se inserta o elimina, sin también del 
número de tupias del grupo. 

En lugar de eso, para tratar el caso de avg, se 
conservan los valores de agregación sum y count 
como se describieron anteriormente y se calcula 
el promedio como la suma dividida por la cuenta. 

• min, max: Considérese una vista materializada 
v = A Q min(R) ( r). (El caso de max es completamen¬ 
te equivalente.) 

El tratamiento de las inserciones en r es inme¬ 
diato. La conservación de los valores de agrega¬ 
ción min y max para las eliminaciones puede 
resultar más costoso. Por ejemplo, si la tupia 
correspondiente al valor mínimo para un grupo se 
elimina de r, hay que examinar las demás tupias 
de r que están en el mismo grupo para hallar el 
nuevo valor mínimo. 

14.5.2.4. Otras operaciones 

La operación de conjuntos intersección se conserva de la 
manera siguiente. Dada la vista materializada v = r D s, 
cuando una tupia se inserta en r se comprueba si está pre¬ 
sente en 5 y, en caso afirmativo, se añade a v. Si se elimi¬ 
na una tupia de r, se elimina de la intersección si se halla 
presente. 

Las otras operaciones con conjuntos, unión y dife¬ 
rencia de conjuntos, se tratan de manera parecida; los 
detalles se dejan al lector. 

Las reuniones extemas se tratan de manera muy pare¬ 
cida a las reuniones, pero con algún trabajo adicional. 
En el caso de la eliminación de r hay que manejar las 
tupias de s que ya no coinciden con ninguna tupia de r. 
En el caso de una inserción en r, hay que manejar las 
tupias de s que no coincidían con ninguna tupia de r. 
De nuevo se dejan los detalles al lector. 

14.5.2.5. Tratamiento de expresiones 

Hasta ahora se ha visto el modo de actualizar de mane¬ 
ra incremental el resultado de una sola operación. Para 
tratar una expresión entera se pueden obtener expre¬ 
siones para el cálculo del cambio incremental en el resul¬ 
tado de cada subexpresión, comenzando por las de 
menor tamaño. 

Por ejemplo, supóngase que se desea actualizar de 
manera incremental la vista materializada £j ix E 2 cuan¬ 
do se inserta un conjunto de tupias i r en la relación r. 


Supóngase que r se utiliza sólo en £j. Supóngase que el 
conjunto de tupias que se va a insertar en £j viene dado 
por la expresión D l . Entonces, la expresión D¡ ix E 2 da 
el conjunto de tupias que hay que insertar en £j IX E 2 . 

Véanse las notas bibliográficas para obtener más deta¬ 
lles sobre la conservación incremental de las vistas con 
expresiones. 

14.5.3. Optimización de consultas y vistas 
materializadas 

La optimización de consultas puede llevarse a cabo tra¬ 
tando las vistas materializadas igual que a las relacio¬ 
nes normales. No obstante, las vistas materializadas 
ofrecen más oportunidades para la optimización: 

• Reescritura de las consultas para el empleo de vis¬ 
tas materializadas: 

Supóngase que está disponible la vista materia¬ 
lizada v = r X sy que un usuario emite la consul¬ 
ta r X 5 X t. Puede que la reescritura de la consulta 
como v X t proporcione un plan de consulta más 
eficiente que la optimización de la consulta tal y 
como se ha emitido. Por tanto, es función del opti- 
mizador de consultas reconocer si se puede utilizar 
una vista materializada para acelerar una consulta. 

• Sustitución del empleo de una vista materializada 
por la definición de la vista: 

Supóngase que está disponible la vista mate¬ 
rializada v = r X s, pero sin ningún índice defini¬ 
do sobre ella, y que un usuario emite la consulta 
o A= 10 (v). Supóngase también que 5 tiene un índi¬ 
ce sobre el atributo común B, y que r tiene un índi¬ 
ce sobre el atributo A. Puede que el mejor plan para 
esta consulta sea sustituir v por r X s, lo que pue¬ 
de llevar al plan de consulta o A=10 (¡j x s\ la selec¬ 
ción y la reunión pueden llevarse a cabo de mane¬ 
ra eficiente empleando los índices sobre r.A y sobre 
s.B, respectivamente. Por el contrario, puede que 
la evaluación de la selección directamente sobre v 
necesite una exploración completa de v, lo que 
puede resultar más costoso. 

Las notas bibliográficas dan indicaciones para inves¬ 
tigar el modo de llevar a cabo de manera eficiente la 
optimización de las consultas con vistas materializadas. 

Otro problema de optimización relacionado es el de 
la selección de las vistas materializadas, es decir, la 
identificación del mejor conjunto de vistas para su mate¬ 
rialización. Esta decisión debe tomarse con base en la car¬ 
ga de trabajo del sistema, que es una secuencia de con¬ 
sultas y de actualizaciones que refleja la carga típica del 
sistema. Un criterio sencillo sería la selección de un con¬ 
junto de vistas materializadas que minimice el tiempo 
global de ejecución de la carga de trabajo de consultas y 
de actualizaciones, incluido el tiempo empleado para con¬ 
servar las vistas materializadas. Los administradores de 
bases de datos suelen modificar este criterio para tener en 
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cuenta la importancia de las diferentes consultas y actua¬ 
lizaciones: puede ser necesaria una respuesta rápida para 
algunas consultas y actualizaciones, mientras que puede 
resultar aceptable una respuesta lenta para otras. Los índi¬ 
ces son como las vistas materializadas, en el sentido de 
que también son datos obtenidos, pueden acelerar las con¬ 
sultas y pueden desacelerar las actualizaciones. Por tan¬ 
to, el problema de la selección de índices se halla ínti¬ 
mamente relacionado con el de la selección de las vistas 
materializadas, aunque resulta más sencillo. 


Estos problemas se examinan con más detalle en los 
apartados 21.2.5 y 21.2.6. 

Algunos sistemas de bases de datos, como SQL Ser- 
ver 7.5 de Microsoft y RedBrick Data Warehouse de 
Informix, proporcionan herramientas para ayudar a los 
administradores de bases de datos en la selección de los 
índices y de las vistas materializadas. Estas herramien¬ 
tas examinan el historial de consultas y de actualiza¬ 
ciones y sugieren los índices y las vistas que hay que 
materializar. 


14.6. RESUMEN 


• Dada una consulta, suele haber gran variedad de méto¬ 
dos para calcular la respuesta. Es responsabilidad del 
sistema transformar la consulta tal y como la intro¬ 
dujo el usuario en una consulta equivalente que pue¬ 
da calcularse de manera más eficiente. El proceso de 
búsqueda de una buena estrategia para el procesa¬ 
miento de la consulta se denomina optimización de 
consultas. 

• La evaluación de las consultas complejas implica 
muchos accesos a disco. Dado que la transferencia 
de los datos desde el disco resulta lenta en compara¬ 
ción con la velocidad de la memoria principal y de 
la CPU del sistema informático, merece la pena asig¬ 
nar una cantidad considerable de procesamiento a la 
elección de un método que minimice los accesos al 
disco. 

• La estrategia que escoja el sistema de bases de datos 
para la evaluación de una operación depende del 
tamaño de cada relación y de la distribución de los 
valores dentro de las columnas. Para que puedan 
basar su elección de estrategia en información de con¬ 
fianza, los sistemas de bases de datos almacenan esta¬ 
dísticas para cada relación r. Entre estas estadísticas 
están 

- El número de tupias de la relación r 

- El tamaño del registro (tupia) de la relación r en 
bytes 

- El número de valores diferentes que aparecen en 
la relación r para un atributo determinado 

• Estas estadísticas permiten estimar el tamaño del resul¬ 
tado de varias operaciones, así como el coste de su 
ejecución. La información estadística sobre las rela¬ 
ciones resulta especialmente útil cuando se dispone 
de varios índices para ayudar al procesamiento de una 
consulta. La presencia de estas estructuras tiene una 
influencia significativa en la elección de una estrate¬ 
gia de procesamiento de consultas. 


• Cada expresión del álgebra relacional representa una 
secuencia concreta de operaciones. El primer paso 
para la selección de una estrategia de procesamiento 
de consultas es la búsqueda de una expresión del álge¬ 
bra relacional que sea equivalente a la expresión dada 
y que se estime menos costosa de ejecutar. 

• Hay varias reglas de equivalencia que se pueden 
emplear para transformar una expresión en otra equi¬ 
valente. Estas reglas se emplean para generar de mane¬ 
ra sistemática todas las expresiones equivalentes a la 
consulta dada. 

• Los planes de evaluación alternativa para cada expre¬ 
sión pueden generarse mediante reglas parecidas y se 
puede escoger el plan más económico para todas las 
expresiones. Se dispone de varias técnicas de opti¬ 
mización para reducir el número de expresiones alter¬ 
nativas y los planes que hace falta generar. 

• La heurística se emplea para reducir el número de pla¬ 
nes considerados y, por tanto, para reducir el coste de 
la optimización. Entre las reglas heurísticas para trans¬ 
formar las consultas del álgebra relacional están «Lle¬ 
var a cabo las operaciones de selección tan pronto 
como sea posible», «Llevar a cabo las proyecciones 
tan pronto como sea posible» y «Evitar los productos 
cartesianos». 

• Las vistas materializadas pueden utilizarse para ace¬ 
lerar el procesamiento de las consultas. La conserva¬ 
ción incremental de las vistas es necesaria para actua¬ 
lizar de forma eficiente las vistas materializadas cuando 
se modifican las relaciones subyacentes. El diferen¬ 
cial de cada operación puede calcularse mediante 
expresiones algebraicas que impliquen a los diferen¬ 
ciales de las entradas de la operación. Entre otros 
aspectos relacionados con las vistas materializadas 
están el modo de optimizar las consultas haciendo uso 
de las vistas materializadas disponibles y el modo de 
seleccionar las vistas que hay que materializar. 
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TÉRMINOS DE REPASO 


• Conjunto mínimo de reglas de equivalencia 

• Conservación de las vistas materializadas 

- Recálculo 

- Mantenimiento incremental 

- Inserción 

- Eliminación 

- Actualización 

• Descorrelación 

• Enumeración de las expresiones equivalentes 

• Equivalencia de las expresiones 

• Estimación de la estadística 

• Estimación del tamaño 

- Selección 

- Selectividad 

- Reunión 

• Estimación de los valores distintos 

• Evaluación correlacionada 

• Información de catálogo 


Interacción de las técnicas de evaluación 
Optimización basada en el coste 
Optimización de consultas 

Optimización de las consultas con las vistas materia¬ 
lizadas 

Optimización heurística 
Optimización del orden de reunión 

- Algoritmo de programación dinámica 

- Orden de reunión en profundidad por la izquierda 
Reglas de equivalencia 

- Conmutatividad de la reunión 

- Asociatividad de la reunión 
Selección de índices 
Selección del plan de acceso 
Selección de los planes de evaluación 
Selección de las vistas materializadas 
Transformación de las expresiones 
Vistas materializadas 


EJERCICIOS 


14.1. El agrupamiento de los índices puede permitir un acce¬ 
so más rápido a los datos de lo que permiten los índi¬ 
ces no agrupados. Indíquese el momento en que se 
deben crear índices no agrupados pese a las ventajas 
de los índices agrupados. Expliqúese la respuesta. 

14.2. Considérense las relaciones r, (A, B, C), r 2 (C, D, E) 
y r 3 ( E , F ), con las claves principales A, C y E, res¬ 
pectivamente. Supóngase que r¡ tiene 1.000 tupias, r 2 
tiene 1.500 tupias y r 3 tiene 750 tupias. Estímese el 
tamaño de r¡ XI r 2 XI r 3 y diséñese una estrategia efi¬ 
ciente para el cálculo de la reunión. 

14.3. Considérense las relaciones r x (A, B, C), r 2 (C, D, E) 
y r 3 (E, F) del Ejercicio 14.2. Supóngase que no hay 
claves principales, excepto el esquema completo. Sean 
V(C, /-,) 900, V(C, r 2 ) 1100, V (E, r 2 ) 50 y V (E, r 3 ) 
100. Supóngase que r x tiene 1.000 tupias, r 2 tiene 
1.500 tupias y r 3 tiene 750 tupias. Estímese el tama¬ 
ño de /-[ XI r 2 X1 r 3 y diséñese una estrategia eficien¬ 
te para calcular la reunión. 

14.4. Supóngase que se dispone de un árbol B + para ciudad- 
sucursal para la relación sucursal y que no se dispo¬ 
ne de ningún otro índice. Indíquese la mejor manera 
de tratar las siguientes selecciones que implican a la 
negación. 

O-, {ciudad-sucursal < «Arganzuela») ( SllCUrSül ) 
b* O-, (ciudad-sucursal = «Arganzuela») ( sucursal) 

O-, (ciudad-sucursal < «Arganzuela» V activos < 5000) ( SUCUTSQX ) 


14.5. Supóngase que se dispone de un árbol B + para ( nom¬ 
bre-sucursal, ciudad-sucursal) para la relación sucur¬ 
sal. Indíquese la mejor manera de tratar la selección 
siguiente. 

0(c¡udad-sucursal < «Arganzuela») A (activos < 5000) A ( nombre-sucursal = 

= «Centro») (SUCUrSül) 

14.6. Demuéstrese que se cumplen las equivalencias 
siguientes. Expliqúese el modo en que se pueden apli¬ 
car para mejorar la eficiencia de determinadas con¬ 
sultas: 

a. £jM s ( E 2 - Es) = (£j Xl fl E 2 - E x Z? 3 ). 

b. a e ( A g F (E)) = A g F (ct 9 (£)), donde 6 sólo utiliza 
atributos de A. 

c. a e (E x ]x E 2 ) = ct s (E) x E 2 , donde 6 sólo utili¬ 
za atributos de £j. 

14.7. Muéstrese el modo de obtener las equivalencias 
siguientes mediante una secuencia de transformacio¬ 
nes utilizando las reglas de equivalencia del Aparta¬ 
do 14.3.1. 

a- = °fl, (° b 2 (o e 3 

b. o e¡A g 2 (E¡ XI S;j E 2 ) = a 0¡ ( E¡ X 03 ((Jg 2 (E 2 ))), donde d 2 
sólo implica atributos de E 2 

14.8. Para cada uno de los siguientes pares de expresiones, 
dense ejemplos de relaciones que muestren que las 
expresiones no son equivalentes. 
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a. n A (R-S)y n A (R) - II A (S) 

6- °fl<4 ÍAGnmx(B) (fi)) Y AGmax(B) ( CT S<4 W) 

c. En las expresiones anteriores, si las dos aparicio¬ 
nes de max se sustituyeran por ruin, indicar si las 
expresiones serían equivalentes. 

d. (R 3xJ S) 3X Ty R 3X1 (S 3X T) 

En otras palabras, la reunión externa por la izquier¬ 
da no es asociativa. 

(Sugerencia: Supóngase que los esquemas de las 
tres relaciones son R(a, b\), S(a, b2) y T(a, b3), 
respectivamente). 

e. o s (£, HX E 2 ) y £j X o g (¿s 2 ), donde 6 utiliza sólo 
atributos de E 2 

14.9. SQL permite las relaciones con duplicados (Capítulo 
4). 

a. Defínanse las versiones de las operaciones básicas 
del álgebra relacional o, IT, x, M, -, U y H que tra¬ 
bajan en relaciones con duplicados, de manera con¬ 
sistente con SQL. 

b. Compruébese cuáles de las reglas de equivalencia 
de la 1 a la 7.b se cumplen para la versión multi- 
conjunto del álgebra relacional definida en el apar¬ 
tado a. 

14.10. ** Demuéstrese que, con n relaciones, hay (2 (n - 
1))!/(« - 1)! órdenes de reunión diferentes. 

Sugerencia: Un árbol binario completo es aquel 
en el que cada nodo interno tiene exactamente dos 
hijos. Utilícese el hecho de que el número de árboles 
binarios completos diferentes con n nodos hojas es 
1 

"F\ (n-l)J' 

Si se desea, se puede obtener la fórmula para el 
número de árboles binarios completos con n nodos a 
partir de la fórmula para el número de árboles bina¬ 
rios con n nodos. El número de árboles binarios con 
n nodos es „ j, | 2 "j; este número se conoce como 
número de Catalan y su obtención puede hallarse en 
cualquier libro de texto estándar sobre estructuras de 
datos o algoritmos. 

14.11. ** Demuéstrese que el orden de reunión de menor cos¬ 
te puede calcularse en un tiempo 0(3"). Supóngse que 
se puede almacenar y examinar la información sobre 


un conjunto de relaciones (como el orden óptimo de 
reunión para el conjunto y el coste de ese orden de reu¬ 
nión) en un tiempo constante. (Si se encuentra difícil 
este ejercicio, demuéstrese al menos la cota de tiem¬ 
po menos estricta de 0(2 2 ").) 

14.12. Demuéstrese que, si sólo se toman en consideración los 
árboles de reunión en profundidad por la izquierda, 
como en el optimizador System R, el tiempo emplea¬ 
do en buscar el orden de reunión más eficiente es del 
orden de n2". Supóngase que sólo hay un orden inte¬ 
resante. 

14.13. Se dice que un conjunto de reglas de equivalencia 
está completo si, siempre que dos expresiones son 
equivalentes, se puede obtener una de la otra median¬ 
te una secuencia de utilizaciones de las reglas de equi¬ 
valencia. Indíquese si el conjunto de reglas de equi¬ 
valencia que se consideró en el Apartado 14.3.1 es 
completo. Sugerencia: considérese la equivalencia 
0-3 = 5 O) = { }■ 

14.14. Descorrelación: 

a. Escríbase una consulta anidada sobre la relación 
cuenta para buscar para cada sucursal cuyo nom¬ 
bre comience por «B» todas las cuentas con el sal¬ 
do máximo de cada sucursal. 

b. Reescríbase la consulta anterior, sin emplear con¬ 
sultas anidadas; en otras palabras, descorrelació¬ 
nese la consulta. 

c. Diséñese un procedimiento (parecido al descrito 
en el Apartado 14.4.5) para descorrelacionar estas 
consultas. 

14.15. Descríbase el modo de conservar de manera incre- 
mental el resultado de las operaciones siguientes, tan¬ 
to para inserciones como para eliminaciones. 

a. Unión y diferencia de conjuntos 

b. Reunión extema por la izquierda 

14.16. Dese un ejemplo de expresión que defina una vista 
materializada y dos situaciones (conjuntos de esta¬ 
dísticas para las relaciones de entrada y sus diferen¬ 
ciales) tales que la conservación incremental de la vis¬ 
ta sea mejor que su recálculo en una de las situaciones 
y el recálculo sea mejor en la otra. 


NOTAS BIBLIOGRÁFICAS 


El trabajo precursor de Selinger et al. [1979] describe 
la selección del camino de acceso en el optimizador Sys¬ 
tem R, que fue uno de los primeros optimizadores de 
consultas relaciónales. Graefe y McKenna [1993] des¬ 
criben Volcano, un optimizador de consultas basado en 
reglas de equivalencia. El procesamiento de consultas 
en Starburst se describe en Haas et al. [1989]. La opti¬ 
mización de consultas en Oracle se describe brevemente 
en Oracle [1997]. 

La estimación de las estadísticas de los resultados de 
las consultas, como el tamaño del resultado, se aborda 


en Ioannidis y Poosala [1995], Poosala et al. [1996] y 
Ganguly et al. [1996], entre otros. Las distribuciones no 
uniformes de valores causan problemas para la estima¬ 
ción del tamaño y del coste de las consultas. Las técni¬ 
cas de estimación del coste que utilizan histogramas de 
las distribuciones de los valores se han propuesto para 
abordar el problema. Ioannidis y Christodoulakis [1993], 
Ioannidis y Poosala [1995] y Poosala et al. [1996] pre¬ 
sentan los resultado en esta área. 

La búsqueda exhaustiva de todos los planes de con¬ 
sultas no resulta práctica para la optimización de las reu- 
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niones que implican a muchas relaciones y se han pro¬ 
puesto técnicas basadas en la búsqueda aleatoria, que 
no examinan todas las alternativas, loannidis y Wong 
[1987], Swami y Gupta [1988] y loannidis y Kang 
[1990] presentan resultados en esta área. 

loannidis et al. [1992] y Ganguly [1998] han pro¬ 
puesto técnicas de optimización paramétrica de con¬ 
sultas para tratar el procesamiento de las consultas cuan¬ 
do la selectividad de los parámetros de la consulta no 
se conoce en el momento de la optimización. Se calcu¬ 
la un conjunto de planes —uno por cada una de las dife¬ 
rentes selectividades de las consultas — , y el optimiza- 
dor lo almacena, en el momento de la compilación. Uno 
de estos planes se elige en el momento de la ejecución, 
con base en las selectividades reales, evitando el coste 
de la optimización completa en el momento de la eje¬ 
cución. 

Klug [1982] realizó uno de los primeros trabajos 
sobre optimización de expresiones del álgebra relacio- 
nal con funciones de agregación. Entre el trabajo más 
reciente en esta área están Yan y Larson [1995] y Chaud- 
huri y Shim [1994]. La optimización de las consultas 
que contienen reuniones externas se describe en Rosent- 
hal y Reiner [1984], Galindo-Legaria y Rosenthal [1992] 
y Galindo-Legaria [1994]. 

El lenguaje SQL plantea varios desafíos para la opti¬ 
mización de las consultas, incluidas la presencia de valo¬ 
res duplicados y nulos y la semántica de las subconsul¬ 
tas anidadas. La extensión del álgebra relacional a los 
valores duplicados se describe en Dayal et al. [1982]. 
La optimización de las subconsultas anidadas se trata 
en Kim [1982], Ganski y Wong [1987], Dayal [1987] 
y, más recientemente, en Seshadri et al. [1996]. 

Cuando las consultas se generan mediante vistas, se 
suelen reunir más relaciones de las necesarias para el 
cálculo de cada consulta. Se ha agrupado un conjunto 
de técnicas para la minimización de las reuniones bajo 
el nombre de optimización con tableau. El concepto de 
tableau lo introdujeron Aho et al. [1979b] y Aho et al. 
[1979a] y lo ampliaron Sagiv y Yannakakis [1981]. Ull- 
man [1988] y Maier [1983] proporcionan un tratamiento 
de tableau con un nivel de libro de texto. 


Sellis [1988] y Roy et al. [2000] describen la optimi¬ 
zación multiconsulta, que es el problema de optimiza¬ 
ción de la ejecución de varias consultas como si fueran 
un grupo. Si se toma en consideración todo un grupo de 
consultas, resulta posible descubrir subexpresiones comu¬ 
nes que pueden evaluarse una sola vez para todo el gru¬ 
po. Linkelstein [1982] y Hall [1976] consideran la opti¬ 
mización de un grupo de consultas y el empleo de las 
subexpresiones comunes. Dalvi et al. [2001] estudian los 
problemas de optimización en los encauzamientos con 
espacio de memorias intermedias limitado combinadas 
con el compartimiento de subexpresiones comunes. 

La optimización de consultas puede hacer uso de la 
información semántica, como las dependencias funcio¬ 
nales y otras restricciones de integridad. La optimiza¬ 
ción semántica de las consultas en las bases de datos 
relaciónales se estudia en King [1981], Chakravarthy et 
al. [1990] y, en el contexto de la agregación, en Sudars- 
han y Ramakrishnan [1991]. 

Las técnicas de procesamiento y de optimización de 
consultas para Datalog, en especial las técnicas para tra¬ 
tar las consultas sobre las vistas recursivas se describen 
en Bancilhon y Ramakrishnan [1986], Beeri y Rama¬ 
krishnan [1991], Ramakrishnan et al. [1992c], Srivas- 
tava et al. [1995] y Mumick et al. [1996]. Las técnicas 
de procesamiento y de optimización de consultas para 
las bases de datos orientadas a los objetos se estudian 
en Maier y Stein [1986], Beech [1988], Bertino y Kim 
[1989] y Blakeley et al. [1993]. 

Blakeley et al. [1986], Blakeley et al. [1989] y Grif- 
fin y Libkin [1995] describen las técnicas para la con¬ 
servación de las vistas materializadas. Gupta y Mumick 
[1995] proporcionan una reseña de la conservación de 
las vistas materializadas. La optimización de los planes 
de conservación de las vistas materializadas se describe 
en Vista [1998] y Mistry et al. [2001]. La optimización 
de consultas en presencia de vistas materializadas se 
aborda en Larson y Yang [1985], Chaudhuri et al. [1995], 
Dar et al. [1996] y Roy et al. [2000]. La selección de 
índices y la selección de vistas materializadas se aborda 
en Ross et al. [1996], Labio et al. [1997], Gupta [1997], 
Chaudhuri y Narasayya [1997] y Roy et al. [2000]. 
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PARTE 


V 


GESTIÓN 

DE TRANSACCIONES 


E l término transacción hace referencia a un conjunto de operaciones que 
forman una única unidad lógica de trabajo. Por ejemplo, la transferen¬ 
cia de dinero de una cuenta a otra es una transacción que consta de dos 
actualizaciones, una para cada cuenta. 

Resulta importante que, o bien se ejecuten completamente todas las accio¬ 
nes de una transacción, o bien, en caso de fallo, se deshagan los efectos par¬ 
ciales de la transacción. Esta propiedad se denomina atomicidad. Además, una 
vez ejecutada con éxito una transacción, sus efectos deben persistir en la base 
de datos: un fallo en el sistema no debe tener como consecuencia que la base 
de datos se olvide de una transacción que haya completado con éxito. Esta pro¬ 
piedad se denomina durabilidad. 

En los sistemas de bases de datos en los que se ejecutan de manera concu¬ 
rrente varias transacciones, si no se controlan las actualizaciones de los datos 
compartidos existe la posibilidad de que las transacciones vean estados inter¬ 
medios inconsistentes creados por las actualizaciones de otras transacciones. 
Esta situación puede dar lugar a actualizaciones erróneas de los datos alma¬ 
cenados en la base de datos. Por tanto, los sistemas de bases de datos deben 
proporcionar los mecanismos para aislar las transacciones de otras transac¬ 
ciones que se ejecuten de manera concurrente. Esta propiedad se denomina 
aislamiento. 

El Capítulo 15 describe con detalle el concepto de transacción, incluidas las 
propiedades de atomicidad, durabilidad, aislamiento y otras propiedades pro¬ 
porcionadas por la abstracción de las transacciones. En concreto, el capítulo 
precisa el concepto de aislamiento por medio de un concepto denominado 
secuencialidad. 

El Capítulo 16 describe varias técnicas de control de la concurrencia que ayu¬ 
dan a implementar la propiedad del aislamiento. 

El Capítulo 17 describe el componente de las bases de datos para la admi¬ 
nistración de las recuperaciones, que implementa las propiedades de atomici¬ 
dad y de durabilidad. 


CAPÍTULO 


15 


A menudo, desde el punto de vista del usuario de una base de datos, se considera a un 
conjunto de varias operaciones sobre una base de datos como una única operación. Por 
ejemplo, una transferencia de fondos desde una cuenta corriente a una cuenta de aho¬ 
rros es una operación simple desde el punto de vista del cliente; sin embargo, en el sistema de 
base de datos, está compuesta internamente por varias operaciones. Evidentemente es esencial 
que tengan lugar todas las operaciones o que, en caso de fallo, ninguna de ellas se produzca. 
Sería inaceptable efectuar el cargo de la transferencia en la cuenta corriente y que no se abo¬ 
nase en la cuenta de ahorros. 

Se llama transacción a una colección de operaciones que forman una única unidad lógica 
de trabajo. Un sistema de base de datos debe asegurar que la ejecución de las transacciones se 
realice adecuadamente a pesar de la existencia de fallos: o se ejecuta la transacción completa 
o no se ejecuta en absoluto. Además debe gestionar la ejecución concurrente de las transaccio¬ 
nes evitando introducir inconsistencias. Volviendo al ejemplo de la transferencia de fondos, una 
transacción que calcule el saldo total del cliente podría ver el saldo de la cuenta corriente antes 
de que sea cargado por la transacción de la transferencia de fondos, y el saldo de la cuenta de 
ahorros después del abono. Como resultado, se obtendría un resultado incorrecto. 

Este capítulo es una introducción a los conceptos básicos en el procesamiento de transac¬ 
ciones. En los Capítulos 16 y 17 se incluyen más detalles sobre el procesamiento concurrente 
de transacciones y la recuperación de fallos. En el Capítulo 24 se tratan temas adicionales acerca 
del procesamiento de transacciones. 


15.1. CONCEPTO DE TRANSACCIÓN 


Una transacción es una unidad de la ejecución de un 
programa que accede y posiblemente actualiza varios 
elementos de datos. Una transacción se inicia por la eje¬ 
cución de un programa de usuario escrito en un lenguaje 
de manipulación de datos de alto nivel o en un lenguaje 
de programación (por ejemplo SQL, COBOL, C, C++ 
o Java), y está delimitado por instrucciones (o llamadas 
a función) de la forma inicio transacción y fin tran¬ 
sacción. La transacción consiste en todas las operacio¬ 
nes que se ejecutan entre inicio transacción y el fin 
transacción. 

Para asegurar la integridad de los datos se necesita 
que el sistema de base de datos mantenga las siguien¬ 
tes propiedades de las transacciones: 

• Atomicidad. O todas las operaciones de la tran¬ 
sacción se realizan adecuadamente en la base de 
datos o ninguna de ellas. 

• Consistencia. La ejecución aislada de la transac¬ 
ción (es decir, sin otra transacción que se ejecute 
concurrentemente) conserva la consistencia de la 
base de datos. 

• Aislamiento. Aunque se ejecuten varias transac¬ 
ciones concurrentemente, el sistema garantiza que 


para cada par de transacciones T¡ y 7j, se cumple 
que para los efectos de T¡, o bien 7) ha terminado 
su ejecución antes de que comience T ¡, o bien que 
Tj ha comenzado su ejecución después de que T¡ 
termine. De este modo, cada transacción ignora al 
resto de las transacciones que se ejecuten concu¬ 
rrentemente en el sistema. 

• Durabilidad. Tras la finalización con éxito de una 
transacción, los cambios realizados en la base de 
datos permanecen, incluso si hay fallos en el sistema. 

Estas propiedades a menudo reciben el nombre de 
propiedades ACID; el acrónimo se obtiene de la pri¬ 
mera letra de cada una de las cuatro propiedades en 
inglés (. Atomicity, Consistency, Isolation y Durability, 
respectivamente). 

Para comprender mejor las propiedades ACID y la 
necesidad de dichas propiedades, considérese un sis¬ 
tema bancario simplificado constituido por varias cuen¬ 
tas y un conjunto de transacciones que acceden y 
actualizan dichas cuentas. Por ahora se asume que la 
base de datos reside permanentemente en disco, pero 
una porción de la misma reside temporalmente en la 
memoria principal. 
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El acceso a la base de datos se lleva a cabo mediante 
las dos operaciones siguientes: 

• leer (A), que transfiere el dato X de la base de datos 
a una memoria intermedia local perteneciente a la 
transacción que ejecuta la operación leer. 

• escribir (J*E), que transfiere el dato X desde la memo¬ 
ria intermedia local de la transacción que ejecuta 
la operación escribir a la base de datos. 

En un sistema de base de datos real, la operación escri¬ 
bir no tiene por qué producir necesariamente una actua¬ 
lización de los datos en disco; la operación escribir puede 
almacenarse temporalmente en memoria y llevarse a disco 
más tarde. Sin embargo, por el momento se supondrá que 
la operación escribir actualiza inmediatamente la base de 
datos. Se volverá a este tema en el Capítulo 17. 

Sea T¡ una transacción para transferir 50 € de la 
cuenta A a la cuenta B. Se puede definir dicha transac¬ 
ción como 

T¡: leer(A); 

A :=A- 50; 

escribir(A); 

leer(5); 

B :=B + 50; 
escribirá). 

Considérense ahora cada uno de los requisitos ACID 
(para una presentación más cómoda, se consideran en 
distinto orden al indicado por A-C-I-D). 

• Consistencia: en este caso el requisito de consis¬ 
tencia es que la suma de A y B no sea alterada al eje¬ 
cutar la transacción. Sin el requisito de consistencia, 
¡la transacción podría crear o destruir dinero! Se 
puede comprobar fácilmente que si una base de datos 
es consistente antes de ejecutar una transacción, sigue 
siéndolo después de ejecutar dicha transacción. 

La responsabilidad de asegurar la consistencia 
de una transacción es del programador de la apli¬ 
cación que codifica dicha transacción. La com¬ 
probación automática de las restricciones de 
integridad puede facilitar esta tarea, como se vio 
en el Capítulo 6. 

• Atomicidad: supóngase que justo antes de ejecu¬ 
tar la transacción T¡ los valores de las cuentas A y 
B son de 1.000 € y de 2.000 €, respectivamente. 
Supóngase ahora que durante la ejecución de la tran¬ 
sacción 7j se produce un fallo que impide que dicha 
transacción finalice con éxito su ejecución. Ejem¬ 
plos de este tipo de fallos pueden ser los fallos en 
la alimentación, los fallos del hardware y los erro¬ 
res software. Además, supóngase que el fallo tiene 
lugar después de ejecutarse la operación escribir(A), 
pero antes de ejecutarse la operación escrib¡r(¿>). Es 
ese caso, los valores de las cuentas A y B que se ven 


reflejados en la base de datos son 950 € y 2.000 €. 
Se han perdido 50 € de la cuenta A como resultado 
de este fallo. En particular se puede ver que ya no 
se conserva la suma A + B. 

Así, como resultado del fallo, el estado del sis¬ 
tema deja de reflejar el estado real del mundo que 
se supone que modela la base de datos. Un estado 
así se denomina estado inconsistente. Hay que ase¬ 
gurarse de que estas inconsistencias no sean visibles 
en un sistema de base de datos. Nótese, sin embargo, 
que un sistema puede en algún momento alcanzar 
un estado inconsistente. Incluso si la transacción T¡ 
se ejecuta por completo, existe un punto en el que 
el valor de la cuenta A es de 950 € y el de la cuenta 
B es de 2.000 €, lo cual constituye claramente un 
estado inconsistente. Este estado, sin embargo, se 
sustituye eventualmente por otro estado consistente 
en el que el valor de la cuenta A es de 950 € y el de 
la cuenta B es de 2.050 €. De este modo, si la tran¬ 
sacción no empieza nunca o se garantiza que se com¬ 
plete, un estado inconsistente así no será visible 
excepto durante la ejecución de la transacción. Esta 
es la razón de que aparezca el requisito de atomici¬ 
dad. Si se proporciona la propiedad de atomicidad, 
o todas las acciones de la transacción se ven refle¬ 
jadas en la base de datos, o ninguna de ellas. 

La idea básica que hay detrás de asegurar la ato¬ 
micidad es la siguiente. El sistema de base de datos 
mantiene los valores antiguos (en disco) de aquellos 
datos sobre los que una transacción realiza una escri¬ 
tura y, si la transacción no completa su ejecución, los 
valores antiguos se recuperan para que parezca que 
la transacción no se ha ejecutado. Estas ideas se mues¬ 
tran más adelante en el Apartado 15.2. La responsa¬ 
bilidad de asegurar la atomicidad es del sistema de 
base de datos; en concreto, lo maneja un componente 
llamado componente de gestión de transacciones, 
que se describe en detalle en el Capítulo 17. 

• Durabilidad: una vez que se completa con éxito 
la ejecución de una transacción, y después de comu¬ 
nicar al usuario que inició la transacción que se ha 
realizado la transferencia de fondos, no debe suce¬ 
der que un fallo en el sistema produzca la pérdida 
de datos correspondientes a dicha transferencia. 

La propiedad de durabilidad asegura que, una vez 
que se completa con éxito una transacción, persis¬ 
ten todas las modificaciones realizadas en la base de 
datos, incluso si hay un fallo en el sistema después 
de completarse la ejecución de dicha transacción. 

A partir de ahora se asume que un fallo en la 
computadora del sistema produce una pérdida de 
datos de la memoria principal, pero los datos alma¬ 
cenados en disco nunca se pierden. Se puede garan¬ 
tizar la durabilidad si se asegura que 

1. Las modificaciones realizadas por la transac¬ 
ción se guardan en disco antes de que finalice 

la transacción. 
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2. La información de las modificaciones realiza¬ 
das por la transacción guardada en disco es sufi¬ 
ciente para permitir a la base de datos reconstruir 
dichas modificaciones cuando el sistema se rei¬ 
nicie después del fallo. 

La responsabilidad de asegurar la durabilidad es 
de un componente del sistema de base de datos lla¬ 
mado componente de gestión de recuperaciones. 
El componente de gestión de transacciones y el 
componente de gestión de recuperaciones están 
estrechamente relacionados, y su implementación 
se describe en el Capítulo 17. 

• Aislamiento: incluso si se aseguran las propieda¬ 
des de consistencia y de atomicidad para cada tran¬ 
sacción, si varias transacciones se ejecutan 
concurrentemente, se pueden entrelazar sus ope¬ 
raciones de un modo no deseado, produciendo un 
estado inconsistente. 

Por ejemplo, como se ha visto antes, la base de 
datos es inconsistente temporalmente durante la 
ejecución de la transacción para transferir fondos 
de la cuenta A a la cuenta B, con el total deducido 
escrito ya en A y el total incrementado todavía sin 
escribir en B. Si una segunda transacción que se 
ejecuta concurrente lee A y B en este punto inter¬ 


medio y calcula A + B, observará un valor incon¬ 
sistente. Además, si esta segunda transacción rea¬ 
liza después modificaciones en A y B basándose 
en los valores leídos, la base de datos puede per¬ 
manecer en un estado inconsistente aunque ambas 
transacciones terminen. 

Una solución para el problema de ejecutar tran¬ 
sacciones concurrentemente es ejecutarlas secuen- 
cialmente, es decir, una tras otra. Sin embargo, la 
ejecución concurrente de transacciones produce 
notables beneficios en el rendimiento, como se verá 
en el Apartado 15.4. Se han desarrollado otras solu¬ 
ciones que permiten la ejecución concurrente de 
varias transacciones. 

Los problemas que causa la ejecución concu¬ 
rrente de transacciones se muestra en el Apartado 
15.4. La propiedad de aislamiento asegura que el 
resultado obtenido al ejecutar concurrentemente las 
transacciones es un estado del sistema equivalente 
a uno obtenido al ejecutar una tras otra en algún 
orden. Los principios de aislamiento se presenta¬ 
rán más adelante en el Apartado 15.5. La respon¬ 
sabilidad de asegurar la propiedad de aislamiento 
es de un componente del sistema de base de datos 
llamado componente de control de concurren¬ 
cia, que se presenta en el Capítulo 16. 


15.2. ESTADOS DE UNA TRANSACCIÓN 


En ausencia de fallos, todas las transacciones se com¬ 
pletan con éxito. Sin embargo, como se ha visto antes, 
una transacción puede que no siempre termine su eje¬ 
cución con éxito. Una transacción de este tipo se deno¬ 
mina abortada. Si se pretende asegurar la propiedad de 
atomicidad, una transacción abortada no debe tener 
efecto sobre el estado de la base de datos. Así, cualquier 
cambio que haya hecho la transacción abortada sobre 
la base de datos debe deshacerse. Una vez que se han 
deshecho los cambios efectuados por la transacción 
abortada, se dice que la transacción se ha retrocedido. 
Parte de la responsabilidad del esquema de recupera¬ 
ciones es gestionar las transacciones abortadas. 

Una transacción que termina con éxito se dice que 
está comprometida. Una transacción comprometida 
que haya hecho modificaciones transforma la base de 
datos llevándola a un nuevo estado consistente, que per¬ 
manece incluso si hay un fallo en el sistema. 

Cuando una transacción se ha comprometido no se 
pueden deshacer sus efectos abortándola. La única forma 
de deshacer los cambios de una transacción compro¬ 
metida es ejecutando una transacción compensadora. 
Por ejemplo, si una transacción añade 20 € a una cuenta, 
la transacción compensadora debería restar 20 € de la 
cuenta. Sin embargo, no siempre se puede crear dicha 
transacción compensadora. Por tanto, se deja al usua¬ 


rio la responsabilidad de crear y ejecutar transacciones 
compensadoras, y no la gestiona el sistema de base de 
datos. En el Capítulo 24 se incluye un estudio de las 
transacciones compensadoras. 

Es necesario precisar qué se entiende por termina¬ 
ción con éxito de una transacción. Se establece por tanto 
un modelo simple abstracto de transacción. Una tran¬ 
sacción debe estar en uno de los estados siguientes: 

• Activa, el estado inicial; la transacción permanece 
en este estado durante su ejecución. 

• Parcialmente comprometida, después de ejecu¬ 
tarse la última instrucción. 

• Fallida, tras descubrir que no puede continuar la 
ejecución normal. 

• Abortada, después de haber retrocedido la tran¬ 
sacción y restablecido la base de datos a su estado 
anterior al comienzo de la transacción. 

• Comprometida, tras completarse con éxito. 

El diagrama de estados correspondiente a una tran¬ 
sacción se muestra en la Figura 15.1. Se dice que una 
transacción se ha comprometido sólo si ha llegado al 
estado comprometida. Análogamente, se dice que una 
transacción ha abortado sólo si ha llegado al estado abor- 
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FIGURA 15.1. Diagrama de transición de estado de una transacción. 


tada. Una transacción se dice que ha terminado si se 
ha comprometido o bien se ha abortado. 

Una transacción comienza en el estado activa. 
Cuando acaba su última instrucción pasa al estado de 
parcialmente comprometida. En este punto la transac¬ 
ción ha terminado su ejecución, pero es posible que aún 
tenga que ser abortada, puesto que los datos actuales 
pueden estar todavía en la memoria principal y puede 
producirse un fallo en el hardware antes de que se com¬ 
plete con éxito. 

El sistema de base de datos escribe en disco la infor¬ 
mación suficiente para que, incluso al producirse un 
fallo, puedan reproducirse los cambios hechos por la 
transacción al reiniciar el sistema tras el fallo. Cuando 
se termina de escribir esta información, la transacción 
pasa al estado comprometida. 

Como se ha mencionado antes, se asume que los 
fallos no provocan pérdidas de datos en disco. Las téc¬ 
nicas para tratar las pérdidas de datos en disco se mues¬ 
tran en el Capítulo 17. 

Una transacción llega al estado fallida después de que 
el sistema determine que dicha transacción no puede con¬ 
tinuar su ejecución normal (por ejemplo, a causa de 
errores de hardware o lógicos). Una transacción de este 
tipo se debe retroceder. Después pasa al estado abortada. 
En este punto, el sistema tiene dos opciones: 

• Reiniciar la transacción, pero sólo si la transac¬ 
ción se ha abortado a causa de algún error hard¬ 
ware o software que no lo haya provocado la lógica 
interna de la transacción. Una transacción reini¬ 
ciada se considera una nueva transacción. 

• Cancelar la transacción. Normalmente se hace 
esto si hay algún error interno lógico que sólo se 
puede corregir escribiendo de nuevo el programa 
de aplicación, o debido a una entrada incorrecta o 
debido a que no se han encontrado los datos dese¬ 
ados en la base de datos. 


Hay que tener cuidado cuando se trabaja con escri¬ 
turas externas observables, como en un terminal o en 
una impresora. Cuando una escritura así tiene lugar, no 
puede borrarse puesto que puede haber sido vista fuera 
del sistema de base de datos. Muchos sistemas permi¬ 
ten que tales escrituras tengan lugar sólo después de que 
la transacción llegue al estado comprometida. Una 
manera de implementar dicho esquema es hacer que el 
sistema de base de datos almacene temporalmente cual¬ 
quier valor asociado con estas escrituras externas en 
memoria no volátil, y realice las escrituras actuales sólo 
si la transacción llega al estado comprometida. Si el sis¬ 
tema falla después de que la transacción llegue al estado 
comprometida, pero antes de que finalicen las escritu¬ 
ras externas, el sistema de base de datos puede llevar a 
cabo dichas escrituras externas (usando los datos de la 
memoria no volátil) cuando el sistema se reinicie. 

La gestión de las escrituras extemas puede ser más 
complicada en ciertas situaciones. Por ejemplo, supón¬ 
gase que la acción externa es dispensar dinero en un 
cajero automático y el sistema falla justo antes de que 
se dispense el dinero (se asume que el dinero se dis¬ 
pensa atómicamente). No tiene sentido dispensar el 
dinero cuando se reinicie el sistema, ya que el usuario 
probablemente no esté en el cajero. En tal caso es nece¬ 
sario una transacción compensadora, como devolver el 
dinero a la cuenta del usuario. 

Para algunas aplicaciones puede ser deseable permi¬ 
tir a las transacciones activas que muestren datos a los 
usuarios, particularmente para transacciones de larga 
duración que se ejecutan durante minutos u horas. Por 
desgracia no se puede permitir dicha salida de datos 
observables a no ser que se quiera arriesgar la atomi¬ 
cidad de la transacción. Muchos sistemas de bases de 
datos actuales aseguran la atomicidad y, por lo tanto, 
prohíben esta forma de interacción con el usuario. En el 
Capítulo 24 se describen modelos alternativos que pro¬ 
porcionan transacciones interactivas de larga duración. 
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15.3. IMPLEMENTACIÓN DE LA ATOMICIDAD Y LA DURABILIDAD 


El componente de gestión de recuperaciones de un sis¬ 
tema de base de datos implementa el soporte para la ato¬ 
micidad y la durabilidad. En primer lugar consideramos 
un esquema simple pero extremadamente ineficiente, 
denominado copia en la sombra. Este esquema, que se 
basa en hacer copias de la base de datos, denominadas 
copias sombra, asume que sólo una transacción está 
activa en cada momento. El esquema asume que la base 
de datos es simplemente un archivo en disco. En disco 
se mantiene un puntero llamado puntero_bd que apunta 
a la copia actual de la base de datos. 

En el esquema de copia en la sombra, una transac¬ 
ción que quiera actualizar una base de datos crea pri¬ 
mero una copia completa de dicha base de datos. Todos 
los cambios se hacen en la nueva copia de la base de 
datos dejando la copia original, la copia en la sombra, 
inalterada. Si en cualquier punto hay que abortar la tran¬ 
sacción, la copia nueva simplemente se borra. La copia 
antigua de la base de datos no se ve afectada. 

Si la transacción se completa, se compromete como 
sigue. En primer lugar se consulta al sistema operativo 
para asegurarse de que todas las páginas de la nueva 
copia de la base de datos se han escrito en disco. (En 
los sistemas Unix se usa la orden fsync para este pro¬ 
pósito.) Después de terminar esta orden se actualiza el 
puntero puntero_bd para que apunte a la nueva copia 
de la base de datos; la nueva copia se convierte enton¬ 
ces en la copia de la base de datos actual. La copia anti¬ 
gua de la base de datos se borra después. El esquema se 
describe en la Figura 15.2, en la cual se muestra el estado 
de la base de datos antes y después de la actualización. 

Se dice que la transacción está comprometida en el 
momento en que puntero_bd actualizado se escribe en 
disco. 

Considérese ahora la manera en que esta técnica trata 
los fallos de las transacciones y del sistema. En primer 
lugar, considérese un fallo en la transacción. Si la tran¬ 


sacción falla en algún momento antes de actualizar pun- 
tero_bd, el contenido de la base de datos anterior no se 
ve afectado. Se puede abortar la transacción simple¬ 
mente borrando la nueva copia de la base de datos. Una 
vez que se ha comprometido la transacción, puntero_bd 
apunta a todas las modificaciones que ésta ha realizado 
en la base de datos. De este modo, o todas las modifi¬ 
caciones de la transacción se ven reflejadas o ninguna 
de ellas, independientemente del fallo de la transac¬ 
ción. 

Considérese ahora el resultado de un fallo en el sis¬ 
tema. Supóngase que el sistema falla en algún momento 
antes de escribir en disco el puntero_bd actualizado. 
Entonces cuando se reinicie el sistema, leerá puntero_bd 
y verá el contenido original de la base de datos, y nin¬ 
guno de los efectos de la transacción será visible en la 
base de datos. A continuación supóngase que el sistema 
falla después de actualizar en disco puntero_bd. Antes 
de que el puntero se actualice, todas las páginas actua¬ 
lizadas de la nueva copia de la base de datos se escri¬ 
ben en disco. De nuevo, se asume que una vez que un 
archivo se escribe en disco, su contenido no se daña 
incluso si hay un fallo del sistema. Por tanto, cuando el 
sistema se reinicie, leerá puntero_bd y verá el conte¬ 
nido de la base de datos después que la transacción haya 
realizado todas las modificaciones. 

La implementación depende realmente de que escri¬ 
bir puntero_bd sea una operación atómica; es decir, o 
se escriben todos sus bytes o ninguno de ellos. Si se 
escribieran algunos de los bytes del puntero y otros no, 
el puntero no tendría sentido y al reiniciarse el sistema 
no se podrían encontrar ni la versión anterior ni la nueva 
de la base de datos. Afortunadamente los sistemas de 
disco proporcionan actualizaciones atómicas de bloques 
enteros, o al menos de un sector del disco. En otras pala¬ 
bras, el sistema de disco garantiza la actualización auto¬ 
mática de puntero_bd. siempre que nos aseguremos de 



(a) Antes de la actualización (b) Después de la actualización 


FIGURA 15.2. Técnica de copia en la sombra para la atomicidad y la durabilidad 
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que puntero_bd cabe en un único sector, lo que se puede 
asegurar almacenándolo al comienzo de un bloque. 

De este modo, la implementación de la copia en la 
sombra del componente de gestión de recuperaciones 
asegura las propiedades de atomicidad y durabilidad de 
las transacciones. 

Como ejemplo simple fuera del dominio de las bases 
de datos, considérese una sesión de edición de texto. 
Una sesión completa de edición de texto puede mode¬ 
lar una transacción. Las acciones que ejecuta la tran¬ 
sacción son leer y actualizar el archivo. Guardar el 
archivo cuando se termina de editar corresponde a com¬ 
pletar la transacción de edición; terminar la sesión de 
edición sin guardar el archivo corresponde a abortar la 
transacción de edición. 

Muchos editores de texto usan fundamentalmente la 
implementación que se acaba de describir para asegurar 


que una sesión de edición es como una transacción. Se 
usa un nuevo archivo para almacenar las modificaciones. 
Al finalizar la sesión de edición, si el archivo modificado 
se va a guardar, se usa una orden para renombrar el nuevo 
archivo para que tenga el nombre del archivo actual. Se 
asume que el renombramiento está implementado como 
una operación atómica en el sistema de archivos, y que 
al mismo tiempo borra el archivo antiguo. 

Por desgracia, esta implementación es extremada¬ 
mente ineficiente en el contexto de grandes bases de 
datos, ya que la ejecución de una simple transacción 
requiere copiar la base de datos completa. Además, la 
implementación no permite a las transacciones ejecu¬ 
tarse concurrentemente unas con otras. Existen formas 
prácticas de implementar la atomicidad y durabilidad 
que son mucho menos costosas y más potentes. Estas 
técnicas se estudian en el Capítulo 17. 


15.4. EJECUCIONES CONCURRENTES 


Los sistemas de procesamiento de transacciones per¬ 
miten normalmente la ejecución de varias transaccio¬ 
nes concurrentemente. Permitir varias transacciones que 
actualizan concurrentemente los datos provoca com¬ 
plicaciones en la consistencia de los mismos, como se 
ha visto antes. Asegurar la consistencia a pesar de la eje¬ 
cución concurrente de las transacciones requiere un tra¬ 
bajo extra; es mucho más sencillo exigir que las 
transacciones se ejecuten secuencialmente, es decir, 
una a una, comenzando cada una sólo después de que 
la anterior se haya completado. Sin embargo, existen 
dos buenas razones para permitir la concurrencia. 

• Productividad y utilización de recursos mejo¬ 
radas. Una transacción consiste en varios pasos. 
Algunos implican operaciones de E/S; otros impli¬ 
can operaciones de UCP La UCP y los discos pue¬ 
den trabajar en paralelo en una computadora. Por 
tanto, las operaciones de E/S se pueden realizar en 
paralelo con el procesamiento de la UCP. Se puede 
entonces explotar el paralelismo de la UCP y del 
sistema de E/S para ejecutar varias transacciones 
en paralelo. Mientras una transacción ejecuta una 
lectura o una escritura en un disco, otra puede eje¬ 
cutarse en la UCP mientras una tercera transacción 
ejecuta una lectura o una escritura en otro disco. 
Todo esto incrementa la productividad ( through- 
put) del sistema, es decir, en el número de tran¬ 
sacciones que puede ejecutar en un tiempo dado. 
Análogamente, la utilización del procesador y del 
disco aumenta también; en otras palabras, el pro¬ 
cesador y el disco están menos tiempo desocupa¬ 
dos o sin hacer ningún trabajo útil. 

• Tiempo de espera reducido. Debe haber una mez¬ 
cla de transacciones que se ejecutan en el sistema, 


algunas cortas y otras largas. Si las transacciones se 
ejecutan secuencialmente, la transacción corta debe 
esperar a que la transacción larga anterior se com¬ 
plete, lo cual puede llevar a un retardo impredecible 
en la ejecución de la transacción. Si las transaccio¬ 
nes operan en partes diferentes de la base de datos 
es mejor hacer que se ejecuten concurrentemente, 
compartiendo los ciclos de la UCP y los accesos a 
disco entre ambas. La ejecución concurrente reduce 
los retardos impredecibles en la ejecución de las tran¬ 
sacciones. Además se reduce también el tiempo 
medio de respuesta: el tiempo medio desde que una 
transacción comienza hasta que se completa. 

La razón para usar la ejecución concurrente en una 
base de datos es esencialmente la misma que para usar 
multiprogramación en un sistema operativo. 

Cuando se ejecutan varias transacciones concurren¬ 
temente, la consistencia de la base de datos se puede 
destruir a pesar de que cada transacción individual sea 
correcta. En este apartado se presenta el concepto de 
planificaciones que ayudan a identificar aquellas ejecu¬ 
ciones que garantizan que se asegura la consistencia. 

El sistema de base de datos debe controlar la inte¬ 
racción entre las transacciones concurrentes para evitar 
que se destruya la consistencia de la base de datos. Esto 
se lleva a cabo a través de una serie de mecanismos 
denominados esquemas de control de concurrencia. 
En el Capítulo 16 se estudian los esquemas de control 
de concurrencia; por ahora nos centraremos en el con¬ 
cepto de ejecución concurrente correcta. 

Considérese de nuevo el sistema bancario simplifi¬ 
cado del Apartado 15.1, el cual tiene varias cuentas, y 
un conjunto de transacciones que acceden y modifican 
dichas cuentas. Sean y T 2 dos transacciones para 
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transferir fondos de una cuenta a otra. La transacción 
7j transfiere 50 € de la cuenta A a la cuenta B y se define 
como sigue 

T x : leer(A); 

A := A - 50; 

escribir(A); 

leer(5); 

B :=B + 50; 
escribirá). 

La transacción T 2 transfiere el 10 por ciento del saldo 
de la cuenta A a la cuenta B , y se define 

T 2 : leer(A); 

temp := A * 0.1; 

A := A — temp\ 

escribir(A); 

leer(5); 

B := B + temp; 
escribir (B). 

Supóngase que los valores actuales de las cuentas A 
y B son 1.000 € y 2.000 € respectivamente. Supón¬ 
gase que las dos transacciones se ejecutan de una en 
una en el orden 7j seguida de T 2 . Esta secuencia de eje¬ 
cución se representa en la Figura 15.3. En esta figura 
la secuencia de pasos o instrucciones aparece en orden 
cronológico de arriba abajo, con las instrucciones de 
T l en la columna izquierda y las de T 2 en la derecha. 
Los valores finales de las cuentas Ay B, después de que 
tenga lugar la ejecución de la Figura 15.3, son de 855 € 
y de 2.145 € respectivamente. De este modo, la suma 
total de saldo de las cuentas Ay B —es decir, la suma 
A + B — se conserva tras la ejecución de ambas tran¬ 
sacciones. 

Análogamente, si las transacciones se ejecutan de 
una en una en el orden T 2 seguida de 7,, entonces la 
secuencia de ejecución es la de la Figura 15.4. De nuevo, 
como se esperaba, se conserva la suma A + B y los valo- 


7 

7 2 

leer(A) 

A := A — 50 
escribir(A) 
leer(S) 

B :=B + 50 
escribir(B) 

leer(A) 

temp := A * 0.1 

A := A — temp 

escribir(A) 

leer(B) 

B := B + temp 
escribir(B) 


FIGURA 15.3. Planificación 1 —una planificación secuencial 
en la que T 2 sigue a 7,. 


7, 

7 2 

leer(A) 

A := A - 50 
escribir(A) 
leerCB) 

B =B + 50 
escribir(B) 

leer(A) 

temp :=A*0.1 

A := A - temp 

escribir(A) 

leer(B) 

B ■= B + temp 
escribí r(B) 


FIGURA 15.4. Planificación 2 —una planificación secuencial 
en la cual 7, sigue a 7 2 . 


res finales de las cuentas A y B son de 850 € y de 
2.150 € respectivamente. 

Las secuencias de ejecución que se acaban de des¬ 
cribir se denominan planificaciones. Representan el 
orden cronológico en el que se ejecutan las instruccio¬ 
nes en el sistema. Obviamente una planificación para 
un conjunto de transacciones debe consistir en todas las 
instrucciones de dichas transacciones, y debe conservar 
el orden en que aparecen las instrucciones en cada tran¬ 
sacción individual. Por ejemplo, en la transacción 7j la 
instrucción escribir(A) debe aparecer antes de la ins¬ 
trucción leer(R) en cualquier planificación válida. En 
los párrafos siguientes, planificación 1 se referirá a la 
primera secuencia de ejecución (T l seguida de 7’ 2 ) y pla¬ 
nificación 2 a la segunda secuencia de ejecución ( T 2 
seguida de 7^). 

Estas planificaciones son secuenciales. Cada plani¬ 
ficación secuencial consiste en una secuencia de ins¬ 
trucciones de varias transacciones, en la cual las 
instrucciones pertenecientes a una única transacción 
están juntas en dicha planificación. De este modo, para 
un conjunto de n transacciones existen ni planificacio¬ 
nes secuenciales válidas distintas. 

Cuando el sistema de bases de datos ejecuta con¬ 
currentemente varias transacciones, la planificación 
correspondiente no tiene por qué ser secuencial. Si 
dos transacciones se ejecutan concurrentemente, el 
sistema operativo puede ejecutar una transacción 
durante un tiempo pequeño, luego realizar un cambio 
de contexto, ejecutar la segunda transacción durante 
un tiempo, cambiar de nuevo a la primera transacción 
durante un tiempo y así sucesivamente. Si hay muchas 
transacciones, todas ellas comparten el tiempo de la 
UCP. 

Son posibles muchas secuencias de ejecución, puesto 
que varias instmcciones de ambas transacciones se pue¬ 
den intercalar. En general no es posible predecir exac¬ 
tamente cuántas instrucciones se ejecutarán antes de que 
la UCP cambie a otra transacción. Así, el número de 
planificaciones posibles para un conjunto de n transac¬ 
ciones es mucho mayor que /?! 
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Volviendo al ejemplo anterior supóngase que las dos 
transacciones se ejecutan concurrentemente. Una posi¬ 
ble planificación se muestra en la Figura 15.5. Una vez 
que la ejecución tiene lugar, se llega al mismo estado 
que cuando las transacciones se ejecutan secuencial- 
mente en el orden T l seguida de T 2 . La suma A + B se 
conserva igualmente. 

No todas las ejecuciones concurrentes producen un 
estado correcto. Como ejemplo de esto considérese la 
planificación de la Figura 15.6. Después de ejecutarse 
esta planificación se llega a un estado cuyos valores fina¬ 
les de las cuentas Ay B son de 950 € y de 2.100 € res¬ 
pectivamente. Este estado final es un estado 
inconsistente, ya que se han ganado 50 € al procesar la 
ejecución concurrente. Realmente la ejecución de las 
dos transacciones no conserva la suma A + B. 


E 

E 

leer(A) 

A := A - 50 
escribir(A) 

leer(A) 

temp :=A*0.1 

A := A - temp 
escribir(A) 

leer(B) 

B := B + 50 
escribir(B) 

leer(B) 

B ■= B + temp 
escribir(B) 


FIGURA 15.5. Planificación 3 —una planificación concurrente 
equivalente a la planificación 1. 


E 

E 

leer(A) 

A := A - 50 

leer(A) 

temp :=A*0.1 

A := A - temp 

escribir(A) 

leer(B) 

escribir(A) 

leer(B) 

B =B + 50 
escribir(B) 

B = B + temp 
escribir(B) 


FIGURA 15.6. Planificación 4—una planificación concurrente. 


Si se deja el control de la ejecución concurrente com¬ 
pletamente al sistema operativo, son posibles muchas 
planificaciones, incluyendo las que dejan a la base de 
datos en un estado inconsistente, como la que se acaba 
de describir. Es una tarea del sistema de base de datos 
asegurar que cualquier planificación que se ejecute lleva 
a la base de datos a un estado consistente. El compo¬ 
nente del sistema de base de datos que realiza esta tarea 
se denomina componente de control de concurren¬ 
cia. 

Se puede asegurar la consistencia de la base de datos 
en una ejecución concurrente si se está seguro de que 
cualquier planificación que se ejecute tiene el mismo 
efecto que otra que se hubiese ejecutado sin concu¬ 
rrencia. Es decir, la planificación debe ser, en cierto 
modo, equivalente a una planificación secuencial. Esta 
idea se examina en el Apartado 15.5. 


15.5. SECUENCIALIDAD 


El sistema de base de datos debe controlar la ejecución 
concurrente de las transacciones para asegurar que el 
estado de la base sigue siendo consistente. Antes de exa¬ 
minar cómo debe realizar esta tarea, el sistema de base 
de datos hay que entender primero las planificaciones 
que aseguran la consistencia y las que no. 

Puesto que las transacciones son programas, es difí¬ 
cil calcular cuáles son las operaciones exactas que rea¬ 
liza una transacción y cómo interaccionan las operaciones 
de varias transacciones. Por este motivo no se van a inter¬ 
pretar los tipos de operaciones que puede realizar una 
transacción sobre un elemento de datos. En lugar de esto 
se consideran sólo dos operaciones: leer y escribir. Se 
asume así que entre una instrucción leer(<2) y otra escri- 
bir(<2) sobre un elemento de datos Q , una transacción 
puede realizar una secuencia arbitraria de operaciones 
con la copia Q que reside en la memoria intermedia local 
de dicha transacción. De este modo las únicas opera¬ 


ciones significativas de la transacción son, desde el punto 
de vista de la planificación, las instrucciones leer y escri¬ 
bir. Por tanto, normalmente sólo se mostrarán las ins¬ 
trucciones leer y escribir en las planificaciones, como se 
muestra en la planificación 3 de la Figura 15.7. 

En este apartado se discuten diferentes formas de 
equivalencia de planificación; esto lleva a los concep¬ 
tos de secuencialidad en cuanto a conflictos y secuen- 
cialidad en cuanto a vistas. 

15.5.1. Secuencialidad en cuanto a conflictos 

Considérese una planificación P en la cual hay dos ins¬ 
trucciones consecutivas /, e / ; , pertenecientes a las tran¬ 
sacciones T¡ y Tj respectivamente (i ^ /). Si /, e 7 y se 
refieren a distintos elementos de datos se pueden inter¬ 
cambiar /, e sin afectar al resultado de cualquier ins¬ 
trucción de la planificación. Sin embargo, si /, e / se 
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E 

E 

leer(A) 

escribir(A) 

leer(A) 

escnbir(A) 

leer(B) 

escribir(B) 

leer(B) 

escribir(B) 


FIGURA 15.7. Planificación 3 —sólo se muestran las instruc¬ 
ciones leer y escribir. 

refieren al mismo elemento Q entonces el orden de los 
dos pasos puede ser importante. Puesto que sólo se tie¬ 
nen en cuenta las instrucciones leer y escribir, se deben 
considerar cuatro casos: 

1. 7, = leer(®, 7 ; = leer(®. El orden de /, e 1- no 
importa, puesto que T¡ y 7j leen el mismo valor 
de Q, independientemente del orden. 

2. 7, = leer(®, 7 ; = escribir!®. Si 7, está antes que I¡, 
entonces T¡ no lee el valor de Q que escribe la ins¬ 
trucción Ij de Tj. Si Ij está antes que I¡, entonces 
T¡ lee el valor de Q escrito por Tj. Por tanto, el 
orden de 7, e / / es importante. 

3. 7, = escribir!®, I¡ = leer(®. El orden de 7, e 7 y es 
importante por razones similares a las del caso 
anterior. 

4. 7, = escribid®, 7 y = escribir!®. Puesto que ambas 
instrucciones son operaciones escribir, el orden 
de dichas instrucciones no afecta ni a T¡ ni a Tj. 
Sin embargo, el valor que obtendrá la siguiente 
instrucción leer(® de P sí se ve afectado, ya que 
únicamente se conserva en la base de datos la 
última de las dos instrucciones escribir. Si no hay 
ninguna otra instrucción escribir!® después de 7, 
e lj en P, entonces el orden de 7, e 7 ; afecta direc¬ 
tamente al valor final de Q en el estado de la base 
de datos que se obtiene con la planificación P. 

De esta manera sólo en el caso en el cual 7, e lj son ins¬ 
trucciones leer no tiene importancia el orden de ejecu¬ 
ción de las mismas. 

Se dice que 7, e 7 y están en conflicto si existen ope¬ 
raciones de diferentes transacciones sobre el mismo ele¬ 
mento de datos, y al menos una de esas instrucciones 
es una operación escribir. 

Para ilustrar el concepto de instrucciones conflicti¬ 
vas considérese la planificación 3 mostrada en la Figura 
15.7. La instrucción escribir(A) de Tj está en conflicto 
con la instrucción leer(fl) de Tj. Sin embargo, la ins¬ 
trucción escribir(A) de Tj no está en conflicto con la ins¬ 
trucción leer(TJ) de 7j, ya que las dos instrucciones 
acceden a diferentes elementos de datos. 

Sean 7, e 7 ; instrucciones consecutivas de una plani¬ 
ficación P. Si 7, e lj son instrucciones de transacciones 


diferentes y además 7, e 7 ; no están en conflicto, enton¬ 
ces se puede cambiar el orden de 7, e 7- para obtener una 
nueva planificación P'. Lo esperado es que P sea equi¬ 
valente a P ', ya que todas las instrucciones aparecen en 
el mismo orden en ambas planificaciones salvo 7, e 7 ; -, 
cuyo orden no es importante. 

Puesto que la instrucción escribir(A) de 7j en la pla¬ 
nificación 3 de la Figura 15.7 no está en conflicto con 
la instrucción leer(7?) de Tj, se pueden intercambiar 
dichas instrucciones para generar una planificación equi¬ 
valente, la planificación 5, que se muestra en la Figura 
15.8. Independientemente de cuál sea el estado inicial 
del sistema, las planificaciones 3 y 5 producen el mismo 
estado final del sistema. 

Se puede continuar intercambiando instrucciones no 
conflictivas como sigue: 

• Intercambiar la instrucción leer(7>) de Tj con la ins¬ 
trucción leer(d) de 7j. 

• Intercambiar la instrucción escribir(7?) de Tj con 
la instrucción escribir(A) de Tj. 

• Intercambiar la instrucción escribir(7?) de Tj con 
la instrucción leer(ri) de Tj. 

El resultado final de estos intercambios, como se mues¬ 
tra en la Figura 15.9, es una planificación secuencial. 
Así se muestra que la planificación 3 es equivalente a 
una planificación secuencial. Esta equivalencia implica 
que independientemente del estado inicial, la planifica¬ 
ción 3 produce el mismo estado final que una planifi¬ 
cación secuencial. 

Si una planificación P se puede transformar en otra 
P' por medio de una serie de intercambios de instruc¬ 
ciones no conflictivas, se dice que P y P' son equiva¬ 
lentes en cuanto a conflictos. 

Volviendo a los ejemplos anteriores, se observa que 
la planificación 1 no es equivalente en cuanto a con¬ 
flictos a la planificación 2. Sin embargo, la planifica¬ 
ción 1 es equivalente en cuanto a conflictos a la 
planificación 3, puesto que las instrucciones leer(/i) y 
escribir(7?) de 7j se pueden intercambiar con las ins¬ 
trucciones leer(A) y escribir(A) de Tj. 

El concepto de equivalencia en cuanto a conflictos 
lleva al concepto de secuencialidad en cuanto a con- 
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leer(A) 

escribir(A) 

leer(A) 

leer(B) 

escribir(A) 

escribir(B) 

leer(B) 

escnbir(B) 


FIGURA 15.8. Planificación 5 —planificación 3 después de 
intercambiar un par de instrucciones. 


375 






FUNDAMENTOS DE BASES DE DATOS 


T 

t 2 

leer (A) 
escribir(A) 
leer(B) 
escribir(B) 

leer(A) 

escribir(A) 

leer(B) 

escribiría) 


FIGURA 15.9. Planificación 6—una planificación secuencial 
equivalente a la planificación 3. 

flictos. Se dice que una planificación P es secuenciable 
en cuanto a conflictos si es equivalente en cuanto a 
conflictos a una planificación secuencial. Así, la plani¬ 
ficación 3 es secuenciable en cuanto a conflictos, ya que 
es equivalente en cuanto a conflictos a la planificación 
secuencial 1. 

Finalmente considérese la planificación 7 de la Figura 
15.10; sólo consta de las operaciones significativas de 
las transacciones T 3 y T 4 (es decir, leer y escribir). Esta 
planificación no es secuenciable en cuanto a conflictos, 
ya que no es equivalente ni a la planificación secuen¬ 
cial <T 3 ,T 4 > ni a <T 4 ,T 3 >. 

Es posible encontrar dos planificaciones que pro¬ 
duzcan el mismo resultado y que no sean equivalentes 
en cuanto a conflictos. Por ejemplo, considérese la tran¬ 
sacción T s , la cual transfiere 10 € de la cuenta# a la A. 
Sea la planificación 8 la que se define en la Figura 15.11. 
Se puede afirmar que la planificación 8 no es equiva¬ 
lente en cuanto a conflictos a la planificación secuen¬ 
cial <r i7 r 5 >, ya que en la planificación 8 la instrucción 
escribir(#) de T 5 está en conflicto con la instrucción 
leer(#) de 7j. Por este motivo no se pueden colocar todas 
las instrucciones de Y’¡ antes de las de T 5 intercambiando 
instrucciones no conflictivas consecutivas. Sin embargo, 
los valores finales de las cuentas Ay# son los mismos 
después de ejecutar tanto la planificación 8 como la pla¬ 
nificación secuencial <T l T 5 > —esto es, 960 € y 
2.040 € respectivamente. 

Con este ejemplo se puede observar que existen defi¬ 
niciones de equivalencia de planificaciones que son 
menos rigurosas que la de equivalencia en cuanto a con¬ 
flictos. Para que el sistema pueda determinar que el 
resultado de la planificación sea el mismo que el de la 
planificación secuencial <T l T 5 >, debe analizar los cál¬ 
culos realizados por T { y T 5 , en lugar de tener sólo en 
cuenta las operaciones leer y escribir. En general es difí¬ 
cil de implementar tal análisis y es caro en términos de 
cómputo. Sin embargo, existen otras definiciones de 
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escribirte?) 
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FIGURA 15.10. Planificación 7. 
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t 5 

leer(A) 

A := A - 50 
escribir(A) 

leer (B) 

B =B- 10 
escribir(B) 

leer(fi) 

B =B + 50 
escribirte) 

leer(A) 

A :=A + 10 
escribir (A) 


FIGURA 15.11. Planificación 8. 


equivalencia de planificación que se basan únicamente 
en las operaciones leer y escribir. En el siguiente apar¬ 
tado se considera una de estas definiciones. 

15.5.2. Secuencialidad en cuanto a vistas 

En este apartado se va a considerar una forma de equi¬ 
valencia que es menos rigurosa que la equivalencia en 
cuanto a conflictos, pero que, al igual que ésta, se basa 
únicamente en las operaciones leer y escribir de las tran¬ 
sacciones. 

Considérense dos planificaciones, PyP', en las cua¬ 
les participa el mismo conjunto de transacciones. Se 
dice que las planificaciones PyP' son equivalentes en 
cuanto a vistas si se cumplen las tres condiciones 
siguientes: 

1. Para todo elemento de datos Q, si la transacción 
T¡ lee el valor inicial de Q en la planificación P, 
entonces T¡ debe leer también el valor inicial de 
Q en la planificación #'. 

2. Para todo elemento de datos Q, si la transacción 
Tj ejecuta leer(<2) en la planificación P y el valor 
lo ha producido la transacción 7j (si existe dicha 
transacción) entonces, en la planificación #', la 
transacción T¡ debe leer también el valor de Q que 
haya producido la transacción T¡. 

3. Para todo elemento de datos Q, la transacción (si 
existe) que realice la última operación escribir(<2) 
en la planificación P, debe realizar la última ope¬ 
ración escribir(2) en la planificación #'. 

Las condiciones 1 y 2 aseguran que cada transacción 
lee los mismos valores en ambas planificaciones y por 
tanto realizan los mismo cálculos. La condición 3, junto 
con las condiciones 1 y 2, asegura que ambas planifi¬ 
caciones dan como resultado el mismo estado final del 
sistema. 

Volviendo a los ejemplos anteriores, nótese que la 
planificación 1 no es equivalente en cuanto a vistas a la 
planificación 2, ya que en la planificación 1 el valor de 
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la cuenta A que lee la transacción 7’ 2 lo produce T x , mien¬ 
tras que esto no ocurre en la planificación 2. Sin 
embargo, la planificación 1 es equivalente en cuanto a 
vistas a la planificación 3, ya que los valores de las cuen¬ 
tas A y B que lee la transacción T 2 los produce T l en 
ambas planificaciones. 

El concepto de equivalencia en cuanto a vistas lleva 
al concepto de secuencialidad en cuanto a vistas. Se dice 
que la planificación P es secuenciable en cuanto a vis¬ 
tas si es equivalente en cuanto a vistas a una planifica¬ 
ción secuencial. 

Como ejemplo supóngase que se aumenta la plani¬ 
ficación 7 con la transacción T b y se obtiene la planifi¬ 
cación 9, como se muestra en la Figura 15.12. La 
planificación 9 es secuenciable en cuanto a vistas. Real¬ 
mente es equivalente en cuanto a vistas a la planifica¬ 
ción secuencial <T 3 ,T 4 ,T¿>, ya que la instmcción leer((9) 


lee el valor inicial de Q en ambas planificaciones, y T 6 
realiza la escritura final de Q en ambas planificaciones. 

Toda planificación secuenciable en cuanto a con¬ 
flictos es secuenciable en cuanto a vistas, pero existen 
planificaciones secuenciables en cuanto a vistas que no 
son secuenciables en cuanto a conflictos. Realmente, la 
planificación 9 no es secuenciable en cuanto a conflic¬ 
tos, puesto que para todo par de instrucciones éstas están 
en conflicto y, por tanto, no es posible ningún inter¬ 
cambio de instrucciones. 

Obsérvese que en la planificación 9, las transaccio¬ 
nes r 4 y T 6 realizan operaciones escribir!(9) sin haber 
realizado ninguna operación leer((9). Este tipo de escri¬ 
turas se denominan escrituras a ciegas. Las escrituras 
a ciegas aparecen en toda planificación secuenciable en 
cuanto a vistas que no sea secuenciable en cuanto a con¬ 
flictos. 


15.6. RECUPERABILIDAD 


Antes se han estudiado las planificaciones que son acep¬ 
tables desde el punto de vista de la consistencia de la 
base de datos asumiendo implícitamente que no había 
fallos en las transacciones. Ahora se va a estudiar el 
efecto de los fallos en una transacción durante una eje¬ 
cución concurrente. 

Si la transacción T¡ falla, por la razón que sea, es nece¬ 
sario deshacer el efecto de dicha transacción para ase¬ 
gurar la propiedad de atomicidad de la misma. En un 
sistema que permita la concurrencia es necesario asegu¬ 
rar también que toda transacción 7’ ; que dependa de T¡ (es 
decir, 7' ; lee datos que ha escrito T¡) se aborta también. 
Para alcanzar esta garantía, es necesario poner res¬ 
tricciones al tipo de planificaciones permitidas en el sis¬ 
tema. 

En los dos subapartados siguientes se estudian las 
planificaciones que son aceptables desde el punto de 
vista que se ha descrito. Como ya se dijo antes, en el 
Capítulo 16 se describe la manera de asegurar que sólo 
se generan dichas planificaciones aceptables. 

15.6.1. Planificaciones recuperables 

Considérese la planificación 11 que se muestra en la 
Figura 15.13, en la cual la transacción T g realiza sólo 
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FIGURA 15.12. Planificación 9—una planificación secuen¬ 
ciable en cuanto a vistas. 


una instrucción: leer(ri). Supóngase que el sistema per¬ 
mite que Tg se complete inmediatamente después de eje¬ 
cutar la instrucción leer(A). Así se completa T g antes de 
que lo haga T H . Supóngase ahora que T s falla antes de 
completarse. Puesto que T g ha leído el valor del ele¬ 
mento de datos A escrito por T s , se debe abortar T g para 
asegurar la atomicidad de la transacción. Sin embargo, 
T g ya se ha comprometido y no puede abortarse. De este 
modo se llega a una situación en la cual es imposible 
recuperarse correctamente del fallo de T s . 

La planificación 11, cuyo compromiso tiene lugar 
inmediatamente después de ejecutar la instrucción 
leer(A), es un ejemplo de planificación no recuperable, 
la cual no debe permitirse. La mayoría de los sistemas 
de bases de datos requieren que todas las planificacio¬ 
nes sean recuperables. Una planificación recuperable 
es aquella en la que para todo par de transacciones T¡ y 
7j tales que 7 j lee elementos de datos que ha escrito pre¬ 
viamente 7j, la operación comprometer de T¡ aparece 
antes que la de T¡. 

15.6.2. Planificaciones sin cascada 

Incluso si una planificación es recuperable, hay que retro¬ 
ceder varias transacciones para recuperar correctamente 
el estado previo a un fallo en una transacción T¡. Tales 
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FIGURA 15.13. Planificación 11. 
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situaciones ocurren si las transacciones leen datos que 
ha escrito T¡. Como ejemplo considérese la planificación 
parcial de la Figura 15.14. La transacción 7j 0 escribe un 
valor de A que lee la transacción T n . La transacción T n 
escribe un valor de A que lee la transacción T n . Supón¬ 
gase que en ese momento falla T l0 . Se debe retroceder 
T l0 . Puesto que 7j, depende de 7j (l , se debe retroceder 
T n . Puesto que 7j 2 depende de T u , se debe retroceder 
T n . Este fenómeno en el cual un fallo en una única tran¬ 
sacción provoca una serie de retrocesos de la transac¬ 
ción se denomina retroceso en cascada. 


No es deseable el retroceso en cascada, ya que pro¬ 
voca un aumento significativo del trabajo necesario para 
deshacer cálculos. Es deseable restringir las planificacio¬ 
nes a aquellas en las que no puedan ocurrir retrocesos en 
cascada. Tales planificaciones se denominan planifica¬ 
ciones sin cascada. Una planificación sin cascada es 
aquella para la que todo par de transacciones T¡ y 7j tales 
que Tj lee un elemento de datos que ha escrito previamente 
T¡, la operación comprometer de T¡ aparece antes que la 
operación de lectura de T. Es sencillo comprobar que toda 
planificación sin cascada es también recuperable. 


15.7. IMPLEMENTACIÓN DEL AISLAMIENTO 


Antes se han visto las propiedades que debe tener una 
planificación para dejar a la base de datos en un estado 
consistente y para permitir fallos en la transacción que 
se puedan manejar de una manera segura. En concreto, 
las planificaciones que son secuenciables en cuanto a 
conflictos o secuenciables en cuanto a vistas y sin cas¬ 
cada cumplen estos requisitos. 

Existen varios esquemas de control de concurren¬ 
cia que se pueden utilizar para asegurar que, incluso si 
se ejecutan concurrentemente muchas transacciones, 
sólo se generen planificaciones aceptables sin tener en 
cuenta la forma en que el sistema operativo comparte 
en el tiempo los recursos (tales como el tiempo de UCP) 
entre las transacciones. 

Como ejemplo trivial de esquema de control de con¬ 
currencia considérese éste: una transacción realiza un 
bloqueo en la base de datos completa antes de comen¬ 
zar y lo libera después de haberse comprometido. Mien¬ 
tras una transacción mantiene el bloqueo, no se permite 
que ninguna otra lo obtenga, y todas ellas deben espe¬ 
rar hasta que se libere el bloqueo. Como resultado de 
esta política de bloqueo, sólo se puede ejecutar una tran¬ 
sacción cada vez. Por tanto, sólo se generan planifica¬ 


ciones secuenciales. Éstas son trivialmente secuencia- 
bles y es sencillo probar que también son sin cascada. 

Un esquema de control de concurrencia como éste 
produce un rendimiento pobre, ya que fuerza a que las 
transacciones esperen a que las transacciones prece¬ 
dentes terminen para poder comenzar. En otras pala¬ 
bras, produce un grado de concurrencia pobre. Como 
se ha explicado en el Apartado 15.4, la ejecución con¬ 
currente tiene varios beneficios en el rendimiento. 

El objetivo de los esquemas de control de concurren¬ 
cia es proporcionar un elevado grado de concurrencia, al 
mismo tiempo que aseguran que todas las planificacio¬ 
nes que se generan son secuenciables en cuanto a con¬ 
flictos o en cuanto a vistas y son sin cascada. 

En el Capítulo 16 se estudian gran número de esque¬ 
mas de control de concurrencia. Los esquemas adoptan 
diferentes compromisos en función del aumento de con¬ 
currencia que permiten y del aumento de coste en el que 
incurren. Algunos permiten que se generen planifica¬ 
ciones secuenciables en cuanto a conflictos; otros per¬ 
miten que se generen planificaciones secuenciables en 
cuanto a vistas que no son secuenciables en cuanto a 
conflictos. 


15.8. DEFINICIÓN DE TRANSACCIONES EN SQL 


Un lenguaje de manipulación de datos debe incluir una 
constructora para especificar el conjunto de acciones 
que constituyen una transacción. 


T, o 

T n 
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leer (A) 
leer(B) 
escribir(A) 
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leer(A) 


FIGURA 15.14. Planificación 12. 


En la norma SQL se especifica el comienzo de una 
transacción explícitamente. Las transacciones se termi¬ 
nan con una de las instrucciones SQL siguientes: 

• Commit work compromete la transacción actual 
y comienza una nueva. 

• Rollback work provoca que la transacción actual 
aborte. 

La palabra clave work es opcional en ambas instruc¬ 
ciones. Si el programa termina sin ninguna de estas 
órdenes, los cambios o bien se comprometen o bien se 
retroceden; en la norma no se especifica cuál de las 
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dos acciones tiene lugar, y depende de la implemen- 
tación. 

La norma especifica también que el sistema debe 
garantizar tanto la secuencialidad como la ausencia de 
retroceso en cascada. La definición de secuencialidad que 
usa la norma es que la planificación debe tener el mismo 
efecto que tendría una planificación secuencial. De este 


modo son aceptables tanto la secuencialidad en cuanto a 
conflictos como la secuencialidad en cuanto a vistas. 

La norma SQL-92 permite también que una tran¬ 
sacción especifique que puede ejecutarse de forma que 
se convierta en no secuenciable con respecto a otras 
transacciones. En el Apartado 16.8 se estudian estos 
niveles más débiles de consistencia. 


15.9. COMPROBACIÓN DE LA SECUENCIALIDAD 


Cuando se diseñan esquemas de control de concurren¬ 
cia hay que demostrar que las planificaciones que genera 
el esquema son secuenciables. Para hacer esto se debe 
entender primero la forma de determinar si, dada una 
planificación concreta P, es secuenciable. 

Ahora se presenta un método simple y eficiente de 
determinar la secuencialidad en cuanto a conflictos de 
una planificación. Considérese una planificación P. Se 
construye un grafo dirigido, llamado grafo de prece¬ 
dencia para P. Este grafo consiste en un par G = (VA), 
siendo V un conjunto de vértices y A un conjunto de 
arcos. El conjunto de vértices consiste en todas las tran¬ 
sacciones que participan en la planificación. El conjunto 
de arcos consiste en todos los arcos T¡ —* 7j para los cua¬ 
les se dan una de las tres condiciones siguientes 

1. T¡ ejecuta escribir(0 antes de que T- ejecute leer(0. 

2. T¡ ejecuta leer(0 antes de que Tj ejecute escribir(0. 

3. T¡ ejecuta escribiría) antes de que Tj ejecute escri¬ 
birte). 

Si existe un arco T¡ —» T¡ en el grafo de precedencia, 
entonces en toda planificación secuencial P' equivalente 
a P, T¡ debe aparecer antes de T ; . 

Por ejemplo, en la Figura 15.15a se muestra el grafo 
de precedencia de la planificación 1. Sólo contiene el 
arco T¡ —> T 2 , puesto que todas las instrucciones de 7j 
se ejecutan antes de que lo haga la primera de T 2 . Aná¬ 
logamente, la Figura 15.15b muestra el grafo de prece¬ 
dencia de la planificación 2 con el único arco T 2 —* T x , 
ya que todas las instrucciones de T 2 se ejecutan antes de 
que lo haga la primera de T { . 

El grafo de precedencia de la planificación 4 se repre¬ 
senta en la Figura 15.16. Contiene el arco T { —> T 2 
debido a que 7j ejecuta leer(A) antes de que T 2 ejecute 
escribir(A). También contiene el arco T 2 —> 7j debido a 
que T 2 ejecuta leer(/i) antes de que / j ejecute escribir!/i). 



(a) (b) 

FIGURA 15.15. Grafo de precedencia para (a) la planifica¬ 
ción 1 y (b) la planificación 2. 



FIGURA 15.16. Grafo de precedencia para la planificación 4. 


Si el grafo de precedencia de P tiene un ciclo, enton¬ 
ces la planificación P no es secuenciable en cuanto a 
conflictos. Si el grafo no contiene ciclos, entonces la 
planificación P es secuenciable en cuanto a conflictos. 

El orden de secuencialidad se puede obtener a tra¬ 
vés de la ordenación topológica, la cual determina un 
orden lineal que consiste en el orden parcial del grafo 
de precedencia. En general se pueden obtener muchos 
órdenes lineales posibles a través de la ordenación topo- 




ib) (c) 


FIGURA 15.17. Ilustración de la ordenación topológica. 
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lógica. Por ejemplo, el grafo de la Figura 15.17a tiene 
dos órdenes lineales aceptables, como se observa en las 
figuras 15.17b y 15.17c. 

Así, para probar la secuencialidad en cuanto a con¬ 
flictos hay que construir el grafo de precedencia e invo¬ 
car a un algoritmo de detección de ciclos. Los algoritmos 
de detección de ciclos se pueden encontrar en cualquier 
libro de texto sobre algoritmos. Los algoritmos de detec¬ 
ción de ciclos, tales como los que se basan en la bús¬ 
queda primero en profundidad, requieren del orden de 
n 1 operaciones, siendo n el número de vértices del grafo 
(es decir, el número de transacciones). De este modo se 
tiene un esquema práctico para determinar la secuen¬ 
cialidad en cuanto a conflictos. 

Volviendo a los ejemplos anteriores, nótese que los 
grafos de precedencia para las planificaciones 1 y 2 
(Figura 15.15) no contienen ciclos. El grafo de prece¬ 


dencia para la planificación 4 (Figura 15.16), sin 
embargo, contiene ciclos, lo que indica que esta plani¬ 
ficación no es secuenciable en cuanto a conflictos. 

La comprobación de la secuencialidad en cuanto a 
vistas es más complicada. De hecho, se ha demostrado 
que el problema de determinar la secuencialidad en 
cuanto a vistas es /VP-completo. Por tanto, seguramente 
no exista ningún algoritmo eficiente para comprobar la 
secuencialidad en cuanto a vistas. Véanse la notas biblio¬ 
gráficas para consultar referencias sobre ello. Sin 
embargo, los esquemas de control de concurrencia aún 
pueden utilizar condiciones suficientes para la secuen¬ 
cialidad en cuanto a vistas. Es decir, si se cumplen las 
condiciones suficientes, la planificación es secuenciali¬ 
dad en cuanto a vistas, pero puede haber algunas plani¬ 
ficaciones secuencialidad en cuanto a vistas que no 
satisfagan las condiciones suficientes. 


15.10. RESUMEN 


• Una transacción es una unidad de la ejecución de un 
programa que accede y posiblemente actualiza varios 
elementos de datos. Es fundamental comprender el 
concepto de transacción para entender e implemen- 
tar las actualizaciones de los datos en una base de 
datos, de manera que las ejecuciones concurrentes y 
los fallos de varios tipos no resulten en que la base de 
datos se vuelva inconsistente. 

• Es necesario que las transacciones tengan las propie¬ 
dades ACID: atomicidad, consistencia, aislamiento y 
durabilidad. 

— La atomicidad asegura que, o bien todos los efec¬ 
tos de la transacción se reflejan en la base de datos, 
o bien ninguno de ellos; un fallo no puede dejar a 
la base de datos en un estado en el cual una tran¬ 
sacción se haya ejecutado parcialmente. 

— La consistencia asegura que si la base de datos es 
consistente inicialmente, la ejecución de la tran¬ 
sacción (debido a la misma) deja la base de datos 
en un estado consistente. 

— El aislamiento asegura que en la ejecución con¬ 
currente de transacciones, están aisladas entre sí, 
de tal manera que cada una tiene la impresión de 
que ninguna otra transacción se ejecuta concu¬ 
rrentemente con ella. 

— La durabilidad asegura que, una vez que la tran¬ 
sacción se ha comprometido, las actualizaciones 
hechas por la transacción no se pierden incluso si 
hay un fallo del sistema. 

• La ejecución concurrente de transacciones mejora la 
productividad y la utilización del sistema, y también 
reduce el tiempo de espera de las transacciones. 

• Cuando varias transacciones se ejecutan concurren¬ 
temente en la base de datos, puede que deje de con¬ 


servarse la consistencia de los datos. Es, por tanto, 
necesario que el sistema controle la interacción entre 
las transacciones concurrentes. 

— Puesto que una transacción es una unidad que con¬ 
serva la consistencia, una ejecución secuencial de 
transacciones garantiza que se conserva dicha con¬ 
sistencia. 

— Una planificación captura las acciones clave de 
las transacciones que afectan a la ejecución con¬ 
currente, tales como las operaciones leer y escri¬ 
bir, a la vez que se abstraen los detalles internos 
de la ejecución de la transacción. 

— Es necesario que toda planificación producida por 
el procesamiento concurrente de un conjunto de 
transacciones tenga el efecto equivalente a una pla¬ 
nificación en la cual esas transacciones se ejecu¬ 
tan secuencialmente en un cierto orden. 

— Un sistema que asegure esta propiedad se dice que 
asegura la secuencialidad. 

— Existen varias nociones distintas de equivalencia 
que llevan a los conceptos de secuencialidad en 
cuanto a conflictos y secuencialidad en cuanto a 
vistas. 

Se puede asegurar la secuencialidad de las planifica¬ 
ciones generadas por la ejecución concurrente de 
transacciones por medio de una gran variedad de 
mecanismos llamados esquemas de control de con¬ 
currencia. 

Las planificaciones deben ser recuperables para ase¬ 
gurar que si la transacción a ve los efectos de la tran¬ 
sacción b y ésta aborta, entonces a también se aborte. 

Las planificaciones deben ser preferentemente sin cas¬ 
cada para que el hecho de abortar una transacción no 
provoque en abortos en cascada de otras transacciones. 
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• El componente de gestión de control de concurrencia 
de la base de datos es el responsable de manejar los 
esquemas de control de concurrencia. En el Capítulo 
16 se describen esquemas de control de concurrencia. 

• El componente de gestión de recuperaciones de la 
base de datos es el responsable de asegurar las pro¬ 
piedades de las transacciones de atomicidad y dura¬ 
bilidad. 

El esquema de copia en la sombra se usa para ase¬ 
gurar la atomicidad y durabilidad en los editores de 


texto; sin embargo, tiene sobrecargas extremadamente 
altas cuando se usa en los sistemas de bases de datos 
y, más aún, no soporta la ejecución concurrente. El 
Capítulo 17 trata esquemas mejores. 

• Se puede comprobar si una planificación es secuen- 
ciable en cuanto a conflictos construyendo el grafo 
de precedencia para dicha planificación y viendo que 
no hay ciclos en el grafo. Sin embargo, hay esquemas 
de control de concurrencia más eficientes para ase¬ 
gurar la secuencialidad. 


TÉRMINOS DE REPASO 


• Bloqueo 

• Conflictos entre operaciones 

• Determinación de la secuencialidad 

• Ejecución secuencial 

• Ejecuciones concurrentes 

• Equivalencia en cuanto a conflictos 

• Equivalencia en cuanto a vistas 

• Escrituras a ciegas 

• Escrituras extemas observables 

• Esquema de control de concurrencia 

• Esquema de copia en la sombra 

• Estado inconsistente 

• Estados de una transacción 
— Abortada 

— Activa 
— Comprometida 
— Fallida 

— Parcialmente comprometida 
— Terminada 


Grafo de precedencia 
Orden de secuencialidad 
Planificaciones 
Planificaciones recuperables 
Planificaciones sin cascada 
Propiedades ACID 

— Aislamiento 

— Atomicidad 

— Consistencia 

— Durabilidad 
Recuperabilidad 
Retroceso en cascada 
Secuencialidad en cuanto a conflictos 
Secuencialidad en cuanto a vistas 
Transacción 

Transacción 

— Cancelar 

— Reiniciar 


EJERCICIOS 


15.1. Lístense las propiedades ACID. Expliqúese la utilidad 
de cada una. 

15.2. Supóngase que existe un sistema de base de datos que 
nunca falla. ¿Se necesita un gestor de recuperaciones 
para este sistema? 

15.3. Considérese un sistema de archivos como el de su sis¬ 
tema operativo preferido. 

a. ¿Cuáles son los pasos involucrados en la creación y 
borrado de archivos, y en la escritura de datos a 
archivos? 

b. Expliqúese por qué son relevantes los aspectos de 
atomicidad y durabilidad en la creación y borrado 
de archivos, y en la escritura de datos a archivos. 

Razónese la respuesta. 


15.4. Los implementadores de sistemas de bases de datos 
prestan mucha más atención a las propiedades ACID 
que los implementadores de sistemas de archivos. ¿Por 
qué tiene sentido esto? 

15.5. Durante su ejecución, una transacción pasa a través de 
varios estados hasta que se compromete o aborta. Lís¬ 
tense todas las secuencias posibles de estados por los 
que puede pasar una transacción. Expliqúese por qué 
puede ocurrir cada una de las transiciones de estados. 

15.6. Justifiqúese lo siguiente. La ejecución concurrente de 
transacciones es más importante cuando los datos se 
deben extraer de disco (lento) o cuando las transaccio¬ 
nes duran mucho, y es menos importante cuando hay 
pocos datos en memoria y las transacciones son muy 
cortas. 
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15.7. Expliqúese la diferencia entre los términos planifica¬ 
ción secuencial y planificación secuenciable. 

15.8. Considérense las dos transacciones siguientes: 

Tp leer(A); 
leer(fi); 

si A = 0 entonces B := B + 1; 
escribir(B). 

T 2 : leer(fi); 
leer(A); 

si B = 0 entonces A := A + 1; 
escribir(A). 

Sea el requisito de consistencia A = 0 v B = 0, siendo 
los valores iniciales A = B = 0. 

a. Demuéstrese que toda ejecución secuencial en la 
que aparezcan estas transacciones conserva la con¬ 
sistencia de la base de datos. 

b. Muéstrese una ejecución concurrente de T l y T 2 
que produzca una planificación no secuenciable. 

c. ¿Existe una ejecución concurrente de 7j y T 2 que 
produzca una planificación secuenciable? 

15.9. Puesto que toda planificación secuenciable en cuanto 
a conflictos es secuenciable en cuanto a vistas, ¿por 
qué se hace hincapié en la secuencialidad en cuanto 
a conflictos en vez de en la secuencialidad en cuanto a 
vistas? 


15.10. Considérese el grafo de precedencia de la Figura 
15.18. ¿Es secuenciable en cuanto a conflictos la pla¬ 
nificación correspondiente? Razónese la respuesta. 

15.11. ¿Qué es una planificación recuperable? ¿Por qué es 
conveniente la recuperabilidad de las planificaciones? 
¿Hay circunstancias bajo las cuales puede ser conve¬ 
niente permitir planificaciones no recuperables? Razó¬ 
nese la respuesta. 

15.12. ¿Qué es una planificación sin cascada? ¿Por qué es 
conveniente la planificación sin cascada? ¿Hay cir¬ 
cunstancias bajo las cuales puede ser conveniente per¬ 
mitir planificaciones que no sean sin cascada? 
Razónese la respuesta. 



FIGURA 15.18. Grafo de precedencia. 


NOTAS BIBLIOGRÁFICAS 


Gray y Reuter [1993] proporcionan un extenso trata¬ 
miento de los conceptos y técnicas de procesamiento 
de transacciones, técnicas y detalles de implementa- 
ción, incluyendo resultados de recuperación y control 
de concurrencia. Bernstein y Newcomer [1997] pro¬ 
porcionan varios aspectos del procesamiento de tran¬ 
sacciones. 

Las primeras discusiones en libro de texto del con¬ 
trol de concurrencia y la recuperación se incluyen en 
Papadimitriou [1986] y Bernstein et al. [1987]. En Gray 
[1978] se presenta una visión de conjunto sobre resul¬ 
tados de implementación de control de concurrencia y 
recuperación. 


El concepto de secuencialidad se formuló en Eswa- 
ran et al. [1976] en conexión con su trabajo sobre con¬ 
trol de concurrencia para System R. Los resultados sobre 
la determinación de secuencialidad y NP-completitud 
de la determinación de la secuencialidad en cuanto a 
vistas son de Papadimitriou et al. [1977] y Papadimi¬ 
triou [1979]. Los algoritmos de detección de ciclos se 
pueden encontrar en libros de algoritmos estándar, como 
en Comen et al. [1990]. 

En los Capítulos 16, 17 y 24 se citan referencias de 
aspectos específicos sobre el procesamiento de tran¬ 
sacciones, como el control de concurrencia y la recu¬ 
peración. 
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CAPÍTULO 



CONTROL DE CONCURRENCIA 


E N el Capítulo 15 se vio que una de las propiedades fundamentales de las transacciones 
es el aislamiento. Cuando se ejecutan varias transacciones concurrentemente en la base 
de datos, puede que deje de conservarse la propiedad de aislamiento. Es necesario que 
el sistema controle la interacción entre las transacciones concurrentes; dicho control se lleva a 
cabo a través de uno de los muchos mecanismos existentes llamado esquemas de control de 
concurrencia. 

Todos los esquemas de control de concurrencia que se describen en este capítulo se basan 
en la propiedad de secuencialidad. Es decir, todos los esquemas que se presentan aquí asegu¬ 
ran que las planificaciones son secuenciables. En el Capítulo 24 se describen esquemas de con¬ 
trol de concurrencia que admiten planificaciones no secuenciables. En este capítulo se trata la 
gestión de la ejecución concurrente de transacciones y se ignoran los fallos. En el Capítulo 17 
se verá la manera en que el sistema se puede recuperar de los fallos. 


16.1. PROTOCOLOS BASADOS EN EL BLOQUEO 


Una forma de asegurar la secuencialidad es exigir que 
el acceso a los elementos de datos se haga en exclusión 
mutua; es decir, mientras una transacción accede a un 
elemento de datos, ninguna otra transacción puede modi¬ 
ficar dicho elemento. El método más habitual que se usa 
para implementar este requisito es permitir que una tran¬ 
sacción acceda a un elemento de datos sólo si posee 
actualmente un bloqueo sobre dicho elemento. 

16.1.1. Bloqueos 

Existen muchos modos mediante los cuales se puede 
bloquear un elemento de datos. En este apartado se cen¬ 
tra la atención en dos de dichos modos: 

1. Compartido. Si una transacción T¡ obtiene un 
bloqueo en modo compartido (denotado por C) 
sobre el elemento Q , entonces T¡ puede leer Q 
pero no lo puede escribir. 

2. Exclusivo. Si una transacción T¡ obtiene un blo¬ 
queo en modo exclusivo (denotado por X) sobre 
el elemento Q , entonces T¡ puede tanto leer como 
escribir Q. 

Es necesario que toda transacción solicite un blo¬ 
queo del modo apropiado sobre el elemento de datos 
Q dependiendo de los tipos de operaciones que se 
vayan a realizar sobre Q. La petición se hace al gestor 
de control de concurrencia. La transacción puede rea¬ 
lizar la operación sólo después de que el gestor de con¬ 
trol de concurrencia conceda el bloqueo a la transac¬ 
ción. 


Dado un conjunto de modos de bloqueo, se puede 
definir sobre ellos una función de compatibilidad como 
sigue. Utilizamos A y B para representar dos modos de 
bloqueo arbitrarios. Supóngase que la transacción T¡ 
solicita un bloqueo en modo A sobre el elemento Q , en 
el que la transacción T¡ (T¡ ^ Tj) posee actualmente un 
bloqueo de modo B. Si a la transacción T¡ se le puede 
conceder un bloqueo sobre Q a pesar de la presencia del 
bloqueo de modo B, entonces se dice que el modo A es 
compatible con el modo B. Tal función se puede repre¬ 
sentar convenientemente en forma de matriz. La rela¬ 
ción de compatibilidad entre los dos modos de bloqueo 
que se usan en este apartado se presenta en la matriz 
comp de la Figura 16.1. Un elemento comp(A, B) de la 
matriz tiene el valor cierto si y sólo si el modo A es com¬ 
patible con el modo B. 

Nótese que el modo compartido es compatible con 
otro modo compartido, pero no con el modo exclusivo. 
En todo momento se pueden tener varios bloqueos en 
modo compartido (por varias transacciones) sobre un 
elemento de datos en concreto. Una petición posterior 
de bloqueo en modo exclusivo debe esperar hasta que 
se liberen los bloqueos en modo compartido que se po¬ 
seen actualmente. 



c 

X 

c 

cierto 

falso 

X 

falso 

falso 


FIGURA 16.1. Matriz de compatibilidad de bloqueo comp. 
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Una transacción solicita un bloqueo compartido sobre 
el elemento de datos Q a través de la instrucción blo- 
quear-C(<2). De forma similar se solicita un bloqueo 
exclusivo a través de la instrucción bloquear-X(0). Se 
puede desbloquear un elemento de datos Q por medio 
de la instrucción desbloquear^). 

Para acceder a un elemento de datos, una transac¬ 
ción T¡ debe en primer lugar bloquear dicho elemento. 
Si éste ya se encuentra bloqueado por otra transacción 
en un modo incompatible, el gestor de control de con¬ 
currencia no concederá el bloqueo hasta que todos los 
bloqueos incompatibles que posean otras transacciones 
hayan sido liberados. De este modo T¡ debe esperar 
hasta que se liberen todos los bloqueos incompatibles 
que posean otras transacciones. 

La transacción T¡ puede desbloquear un elemento de 
datos que haya bloqueado en algún momento anterior. 
Nótese que la transacción debe poseer un bloqueo sobre 
un elemento de datos durante todo el tiempo que acce¬ 
da a dicho elemento. Además, no siempre es aconseja¬ 
ble que una transacción desbloquee un elemento de datos 
inmediatamente después de finalizar su acceso sobre él, 
ya que puede dejar de asegurarse la secuencialidad. 

Como ejemplo, considérese de nuevo el sistema ban- 
cario simplificado que se presentó en el Capítulo 15. 
Sean Ay B dos cuentas a las que acceden las transac¬ 
ciones 7j y T 2 . La transacción 7j transfiere 50 € desde 
la cuenta B a la A (Figura 16.2). La transacción T 2 vi¬ 
sualiza la cantidad total de dinero de las cuentas Ay B 
—es decir, la suma A + B (Figura 16.3). 

Supóngase que los valores de las cuentas Ay B son 
100 € y 200 € respectivamente. Si estas dos transac¬ 
ciones se ejecutan secuencialmente, tanto en el orden 
T x , T 2 como en el orden T 2 , 7j, entonces la transacción 
T 2 visualizará el valor 300 €. Si por el contrario estas 
transacciones se ejecutan concurrentemente, entonces 
puede darse la planificación 1, que se muestra en la Figu¬ 
ra 16.4. En ese caso la transacción T 2 visualiza 250 €, 
lo cual es incorrecto. El motivo por el que se produce 
esta incorrección es que la transacción Yj desbloquea el 
elemento B demasiado pronto, lo cual provoca que T 2 
perciba un estado inconsistente. 

La planificación muestra las acciones que ejecuta 
cada transacción, así como los puntos en los que el ges¬ 
tor de control de concurrencia concede los bloqueos. La 
transacción que realiza una petición de bloqueo no pue- 


leer(B); 

B -B- 50; 

escribir(B); 

desbloquear(B); 

bloquear-X(A); 

leer(A); 

A := A + 50; 

escrlbir(A); 

desbloquear 

FIGURA 16.2. Transacción 7j. 


7): bloquear-C(A); 
leer(A); 

desbloquear(A); 

bloquear-C(B); 

leer(B); 

desbloquear(B); 
visualizar(A + B ). 

FIGURA 16.3. Transacción T 2 . 


de ejecutar su siguiente acción hasta que el gestor de 
control de concurrencia conceda dicho bloqueo. Por tan¬ 
to, el bloqueo debe concederse en el intervalo de tiem¬ 
po entre la operación de petición del bloqueo y la 
siguiente acción de la transacción. No es importante el 
momento exacto del intervalo en el cual se produce la 
concesión del bloqueo; se puede asumir sin problemas 
que la concesión del bloqueo se produce justo antes de 
la siguiente acción de la transacción. Por tanto se va a 
obviar la columna que describe las acciones del gestor 
de control de concurrencia en todas las planificaciones 
que aparezcan en el resto del capítulo. Se deja al lector 
como ejercicio la deducción del momento en que se con¬ 
ceden los bloqueos. 

Supóngase ahora que el desbloqueo se retrasa hasta 
el final de la transacción. La transacción T 3 correspon¬ 
de a T x con el desbloqueo retrasado (Ligura 16.5). La 
transacción T 4 corresponde a r 2 con el desbloqueo retra¬ 
sado (Ligura 16.6). 

Se puede verificar que la secuencia de lecturas y 
escrituras de la planificación 1, que provoca que se 
visualice un total incorrecto de 250 €, ya no es posible 
con T 3 y T 4 . 

Son posibles otras planificaciones. T 4 no visualiza 
un resultado inconsistente en ninguna de ellas; más ade¬ 
lante se verá por qué. 

Por desgracia, el uso de bloqueos puede conducir a 
una situación no deseada. Considérese la planificación 
parcial de la Ligura 16.7 para T 3 y T 4 . Puesto que T 3 
posee en bloqueo sobre B en modo exclusivo y T 4 soli¬ 
cita un bloqueo sobre B en modo compartido, T 4 espe¬ 
ra a que T 3 desbloquee B. De forma similar, puesto que 
T 4 posee un bloqueo sobre A en modo compartido y T 3 
solicita un bloqueo sobre A en modo exclusivo, T 3 espe¬ 
ra a que T 4 desbloquee A. Así se llega a un estado en el 
cual ninguna de las transacciones puede continuar su 
ejecución normal. Esta situación se denomina inter¬ 
bloqueo. Cuando aparece un interbloqueo, el sistema 
debe retroceder una de las dos transacciones. Una vez 
que una de ellas se ha retrocedido, se desbloquean los 
elementos de datos que estuvieran bloqueados por la 
transacción. Estos elementos de datos están disponibles 
entonces para otra transacción, la cual puede continuar 
su ejecución. Se volverá al tratamiento de interbloqueos 
en el Apartado 16.6. 

Si no se usan bloqueos, o se desbloquean los ele¬ 
mentos de datos tan pronto como sea posible después 
de leerlos o escribirlos, se pueden obtener estados 
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L 

t 2 

Gestor de control de concurrencia 

bloquear-X(B) 


conceder-X(B, 7j) 

leer(B) 

B-B-50 

escribir(B) 

desbloquear(B) 

bloquear-C(A) 

conceder-C(A, T 2 ) 


leer(A) 

desbloquear(A) 

bloquear-C(B) 

conceder-C (B, T 2 ) 


leer(B) 

desbloquear(B) 
vlsualizar(A + B) 


bloquear-X(A) 


conceder-X(A, T t ) 

leer (A) 

A := A + 50 

escribir(A) 

desbloquear(A) 




FIGURA 16.4. Planificación 1. 


inconsistentes. Por otro lado, si no se desbloquea un 
elemento de datos antes de solicitar un bloqueo sobre 
otro, pueden producirse interbloqueos. Existen formas 
de evitar los interbloqueos en algunas situaciones, 
como se verá en el Apartado 16.1.5. Sin embargo, en 
general, los interbloqueos son un mal necesario aso¬ 
ciado a los bloqueos si se quieren evitar los estados 
inconsistentes. Los interbloqueos son absolutamente 
preferibles a los estados inconsistentes, ya que se pue¬ 
den tratar retrocediendo las transacciones, mientras 
que los estados inconsistentes producen problemas en 
el mundo real que el sistema de base de datos no pue¬ 
de manejar. 

Se exige que toda transacción del sistema siga un 
conjunto de reglas llamado protocolo de bloqueo, que 
indica el momento en que una transacción puede blo¬ 
quear y desbloquear cada uno de los elementos de datos. 
Los protocolos de bloqueo restringen el número de pla¬ 
nificaciones posibles. El conjunto de tales planificacio¬ 
nes es un subconjunto propio de todas las planificacio¬ 
nes secuenciables posibles. Se van a mostrar varios 
protocolos de bloqueo que sólo permiten planificacio¬ 


r 3 : bloquear-X(B); 
leer(B); 

B :=B- 50; 
escribir(B); 
bloquear-X(A); 
leer(A); 

A := A + 50; 
escribir(A); 
desbloquear(B); 
desbloqueará). 


nes secuenciables en cuanto a conflictos. Antes de hacer 
esto se necesitan algunas definiciones. 

Sean {T 0 ,T { , ... ,T n } un conjunto de transacciones 
que participan en la planificación S. Se dice que T¡ pre¬ 
cede a Tj en S, denotado por T¡ —> 7’ ; , si existe un ele¬ 
mento de datos Q tal que T¡ ha obtenido un bloqueo en 
modo A sobre Q, y T¡ ha obtenido un bloqueo en modo 
B sobre Q más tarde y comp(A,5) = falso. Si T¡ —* T¡ 
entonces esta precedencia implica que en cualquier pla¬ 
nificación secuencial equivalente, T¡ debe aparecer antes 
que T¡. Obsérvese que este grafo es similar al grafo de 
precedencia que se usaba en el Apartado 15.9 para com¬ 
probar la secuencialidad en cuanto a conflictos. Los con¬ 
flictos entre instrucciones corresponden a modos de blo¬ 
queo no compatibles. 

Se dice que una planificación S es legal bajo un pro¬ 
tocolo de bloqueo dado si S es una planificación posi¬ 
ble para un conjunto de transacciones que sigan las 
reglas del protocolo de bloqueo. Se dice que un proto¬ 
colo asegura la secuencialidad en cuanto a conflictos 
si y sólo si todas las planificaciones legales son secuen¬ 
ciables en cuanto a conflictos; en otras palabras, para 
todas las planificaciones legales la relación —> asocia¬ 
da es acíclica. 


T 4 : bloquear-C(A); 
leer(A); 
bloquear-C(B); 
leer(fi); 

visuaiizar(A + B). 

desbloqueará); 

desbloqueará). 

FIGURA 16.6. Transacción T 4 . 


FIGURA 16.5. Transacción T 3 . 
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T 3 

U 

bloquear-X(fi) 

leer(fi) 

B-B-50 

escribir(fi) 

bloquear-C(.A) 

leer(A) 

bloquear-C(5) 

bloquear-X(A) 



FIGURA 16.7. Planificación 2. 

16.1.2. Concesión de bloqueos 

Cuando una transacción solicita un bloqueo de un modo 
particular sobre un elemento de datos y ninguna otra 
transacción posee un bloqueo sobre el mismo elemen¬ 
to de datos en un modo conflictivo, se puede conceder 
el bloqueo. Sin embargo, hay que tener cuidado para 
evitar la siguiente situación. Supóngase que la transac¬ 
ción T 2 posee un bloqueo en modo compartido sobre un 
elemento de datos y que la transacción T x solicita un 
bloqueo en modo exclusivo sobre dicho elemento de 
datos. Obviamente T 1 debe esperar a que T 2 libere el 
bloqueo en modo compartido. Mientras tanto, la tran¬ 
sacción T 3 puede solicitar un bloqueo en modo com¬ 
partido sobre el mismo elemento de datos. La petición 
de bloqueo es compatible con el bloqueo que se ha con¬ 
cedido a T 2 , por tanto se puede conceder a T 3 el bloqueo 
en modo compartido. En este punto T 2 puede liberar el 
bloqueo, pero T l debe seguir esperando hasta que T 3 ter¬ 
mine. Pero de nuevo puede haber una nueva transac¬ 
ción T a que solicite un bloqueo en modo compartido 
sobre el mismo elemento de datos y a la cual se conce¬ 
da el bloqueo antes de que T 3 lo libere. De hecho es posi¬ 
ble que haya una secuencia de transacciones que soli¬ 
citen un bloqueo en modo compartido sobre el elemento 
de datos, y que cada una de ellas libere el bloqueo un 
poco después de que sea concedido, de forma que T l 
nunca obtenga el bloqueo en modo exclusivo sobre el 
elemento de datos. La transacción T x nunca progresa y 
se dice que tiene inanición. 

Se puede evitar la inanición de las transacciones al 
conceder los bloqueos de la siguiente manera: cuando 
una transacción T¡ solicita un bloqueo sobre un ele¬ 
mento de datos Q en un modo particular M, el gestor 
de control de concurrencia concede el bloqueo siem¬ 
pre que 

1. No exista otra transacción que posea un bloqueo 
sobre Q en un modo que esté en conflicto con M. 

2. No exista otra transacción que esté esperando un 
bloqueo sobre Q y que lo haya solicitado antes 
que T¡. 

De este modo, una petición de bloqueo nunca se que¬ 
dará bloqueada por otra petición de bloqueo solicitada 
más tarde. 


16.1.3. Protocolo de bloqueo de dos fases 

Un protocolo que asegura la secuencialidad es el pro¬ 
tocolo de bloqueo de dos fases. Este protocolo exige 
que cada transacción realice las peticiones de bloqueo 
y desbloqueo de dos fases: 

1. Fase de crecimiento. Una transacción puede 
obtener bloqueos pero no puede liberarlos. 

2. Fase de decrecimiento. Una transacción puede 
liberar bloqueos pero no puede obtener ninguno 
nuevo. 

Inicialmente una transacción está en la fase de creci¬ 
miento. La transacción adquiere los bloqueos que nece¬ 
site. Una vez que la transacción libera un bloqueo, entra 
en la fase de decrecimiento y no puede realizar más peti¬ 
ciones de bloqueo. 

Por ejemplo, las transacciones T 3 y T 4 son de dos 
fases. Por otro lado, las transacciones 7j y T 2 no son de 
dos fases. Nótese que no es necesario que las instruc¬ 
ciones de desbloqueo aparezcan al final de la transac¬ 
ción. Por ejemplo, en el caso de la transacción T 3 se pue¬ 
de trasladar la instrucción desbloquear^?) hasta justo 
antes de la instrucción bloquear-X(A) y se sigue cum¬ 
pliendo la propiedad del bloqueo de dos fases. 

Se puede mostrar que el protocolo de bloqueo de 
dos fases asegura la secuencialidad en cuanto a con¬ 
flictos. Considérese cualquier transacción. El punto de 
la planificación en el cual la transacción obtiene su blo¬ 
queo final (el final de la fase de crecimiento) se deno¬ 
mina punto de bloqueo de la transacción. Ahora se 
pueden ordenar las transacciones en base a sus puntos 
de bloqueo; de hecho, esta ordenación es un orden de 
secuencialidad para las transacciones. La demostración 
se deja como ejercicio para el lector (véase el Ejerci¬ 
cio 16.1). 

El protocolo de bloqueo de dos fases no asegura la 
ausencia de interbloqueos. Obsérvese que las transac¬ 
ciones T 3 y r 4 son de dos fases pero en la planificación 
2 (Figura 16.7) llegan a un interbloqueo. 

Recuérdese del Apartado 15.6.2 que las planifica¬ 
ciones, además de ser secuenciables, es aconsejable que 
sean sin cascada. El retroceso en cascada puede ocurrir 
en el bloqueo de dos fases. Como ejemplo considérese 
la planificación parcial de la Figura 16.8. Cada tran¬ 
sacción sigue el protocolo de bloqueo de dos fases pero 
un fallo de T 5 después del paso leer(A) de 7’ 7 lleva a un 
retroceso en cascada de 7’ 6 y 7’ 7 . 

Los retrocesos en cascada se pueden evitar por medio 
de una modificación del protocolo de bloqueo de dos 
fases que se denomina protocolo de bloqueo estricto 
de dos fases. Este protocolo exige que, además de que 
el bloqueo sea de dos fases, una transacción debe po¬ 
seer todos los bloqueos en modo exclusivo que tome 
hasta que dicha transacción se complete. Este requisito 
asegura que todo dato que escribe una transacción no 
comprometida está bloqueado en modo exclusivo has- 
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T 5 

T e 

t 7 

bloquear-X(A) 

leer(A) 

bloquear-C(5) 

leerffi) 

escribir(A) 

desbloquear(A) 

bloquear-X(A) 

leer(A) 

escribir(A) 

desbloquear(A) 

bloquear-C(A) 

leer(A) 


FIGURA 16.8. Planificación parcial con bloqueo de dos fases. 


ta que la transacción se completa, evitando que ningu¬ 
na otra transacción lea el dato. 

Otra variante del bloqueo de dos fases es el protoco¬ 
lo de bloqueo riguroso de dos fases, el cual exige que 
se posean todos los bloqueos hasta que se comprometa 
la transacción. Se puede comprobar fácilmente que con 
el bloqueo riguroso de dos fases se pueden secuenciar 
las transacciones en el orden en que se comprometen. 
Muchos sistemas de bases de datos implementan tanto 
el bloqueo estricto como el bloqueo estricto de dos fases. 

Considérense las dos transacciones siguientes de las 
que sólo se muestran algunas de las operaciones leer y 
escribir significativas: 

r 8 : leeficq); 
leer(a 2 ); 

leer(a„); 

escribida!). 

r 9 : leedcq); 

leer(a 2 ); 

visualizada! + a 2 ). 

Si se emplea el protocolo de bloqueo de dos fases 
entonces T & debe bloquear a l en modo exclusivo. Por 
tanto, toda ejecución concurrente de ambas transaccio¬ 
nes conduce a una ejecución secuencial. Nótese sin 
embargo que 7’ 8 sólo necesita el bloqueo en modo exclu¬ 
sivo sobre a l al final de su ejecución, cuando escribe a,. 
Así, si r 8 pudiera bloquear' inicialmente a, en modo com¬ 
partido y después pudiera cambiar el bloqueo a modo 
exclusivo, se obtendría una mayor concurrencia, ya que 
r 8 y T 9 podrían acceder a a { y a 2 simultáneamente. 

Esta observación lleva a un refinamiento del proto¬ 
colo de bloqueo de dos fases básico en el cual se per¬ 
miten conversiones de bloqueo. Se va a proporcionar 
un mecanismo para cambiar un bloqueo compartido por 
un bloqueo exclusivo y un bloqueo exclusivo por uno 
compartido. Se denota la conversión del modo com¬ 
partido al modo exclusivo como subir, y la conversión 
del modo exclusivo al modo compartido como bajar. 


No se puede permitir la conversión de modos arbitra¬ 
riamente. Por el contrario, la subida puede tener lugar 
sólo en la fase de crecimiento, mientras que la bajada 
puede tener lugar sólo en la fase de decrecimiento. 

Volviendo al ejemplo, las transacciones T g y 7’ y se 
pueden ejecutar concurrentemente bajo el protocolo de 
bloqueo de dos fases refinado, como muestra la plani¬ 
ficación incompleta de la Figura 16.9, en la cual sólo se 
muestran algunas de las operaciones de bloqueo. 

Nótese que se puede forzar a esperar a una transac¬ 
ción que intente subir un bloqueo sobre un elemento Q. 
Esta espera forzada tiene lugar si Q está bloqueado 
actualmente por otra transacción en modo compartido. 

Del mismo modo que el protocolo de bloqueo de dos 
fases básico, el bloqueo de dos fases con conversión de 
bloqueos genera sólo planificaciones secuenciables en 
cuanto a conflictos y se pueden secuenciar las transac¬ 
ciones según sus puntos de bloqueo. Además, si se po¬ 
seen los bloqueos hasta el final de la transacción, las 
planificaciones son sin cascada. 

Para un conjunto de transacciones puede haber pla¬ 
nificaciones secuenciables en cuanto a conflictos que 
no se puedan obtener por medio del protocolo de blo¬ 
queo de dos fases. Sin embargo, para obtener planifi¬ 
caciones secuenciables en cuanto a conflictos por medio 
de protocolos de bloqueo que no sean de dos fases, es 
necesario o bien tener información adicional de las tran¬ 
sacciones o bien imponer alguna estructura u orden en 
el conjunto de elementos de datos de la base de datos. 
En ausencia de esta información es necesario el bloqueo 
de dos fases para la secuencialidad en cuanto a conflic¬ 
tos —si T¡ no es una transacción de dos fases, siempre 
es posible encontrar otra transacción 7’ ; que sea de dos 
fases tal que existe una planificación posible para T¡ y 
Tj que no sea secuenciable en cuanto a conflictos. 

Los bloqueos estricto de dos fases y riguroso de dos 
fases (con conversión de bloqueos) se usan ampliamente 
en sistemas de bases de datos comerciales. 

Un esquema simple pero de uso extendido genera 
automáticamente las instrucciones apropiadas de blo¬ 
queo y desbloqueo para una transacción, basándose 
en peticiones de lectura y escritura desde la transac¬ 
ción: 


t 8 

T 9 

bloquear-Cía^ 

bloquear-Cíad 

bloquear-C(a 2 ) 

bloquear-C(a 2 ) 

bloquear-C(a 3 ) 

bloquear-C(a 4 ) 

desbloquearía!) 

desbloquear(a 2 ) 

bloquear-C(a„) 

subir(a!) 



FIGURA 16.9. Planificación incompleta con conversión de 
bloqueos. 
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• Cuando una transacción T¡ realiza una operación 
leer(0, el sistema genera una instrucción bloque- 
ar-C(0 seguida de una instrucción leer(0. 

• Cuando T¡ realiza una operación escribid 0, el sis¬ 
tema compmeba si T¡ posee ya un bloqueo en modo 
compartido sobre Q. Si es así, entonces el sistema 
genera una instrucción subir(0 seguida de la ins¬ 
trucción escribir(0. En otro caso el sistema gene¬ 
ra una instrucción bloquear-X(0 seguida de la ins¬ 
trucción escribir(0. 

• Todos los bloqueos que obtenga una transacción 
no se desbloquean hasta que dicha transacción se 
comprometa o aborte. 

16.1.4. Implementación de bloqueos ** 

Un gestor de bloqueos se puede implementar como un 
proceso que recibe mensajes de transacciones y envía 
mensajes como respuesta. El proceso gestor de bloqueos 
responde a los mensajes de solicitud de bloqueo con 
mensajes de concesión de bloqueo, o con mensajes que 
solicitan un retroceso de la transacción (en caso de inter¬ 
bloqueos). Los mensajes de desbloqueo tan sólo requie¬ 
ren un reconocimiento como respuesta, pero pueden dar 
lugar a un mensaje de concesión para otra transacción 
que esté esperando. 

El gestor de bloqueos utiliza la siguiente estructura de 
datos: para cada elemento de datos que está actualmente 
bloqueado, mantiene una lista enlazada de registros, uno 
para cada solicitud, en el orden en el que llegaron las soli¬ 
citudes. Utiliza una tabla de asociación, indexada por el 
nombre del elemento de datos, para encontrar la lista enla¬ 
zada (si la hay) para cada elemento de datos; esta tabla se 
denomina tabla de bloqueos. Cada registro de la lista 
enlazada de cada elemento de datos anota qué transacción 
hizo la solicitud, y qué modo de bloqueo se solicitó. El 
registro también anota si la solicitud ya se ha concedido. 

La Figura 16.10 muestra un ejemplo de una tabla de 
bloqueos. La tabla contiene bloqueos para cinco ele¬ 
mentos de datos distintos: E4, E7, E23, E44 y E912. La 
tabla de bloqueos utiliza cadenas de desbordamiento, de 
forma que hay una lista enlazada de elementos de datos 
por cada entrada de la tabla de bloqueos. También hay 
una lista de transacciones a las que se les han concedi¬ 
do bloqueos, o que están esperando para bloquear, para 
cada uno de los elementos de datos. Los bloqueos con¬ 
cedidos se han representado como rectángulos rellenos 
(negros), mientras que las solicitudes en espera son los 
rectángulos vacíos. Se ha omitido el modo de bloqueo 
para que la figura sea más sencilla. Por ejemplo, se pue¬ 
de observar que a T23 se le han concedido bloqueos 
sobre E912 y E7, y está esperando para bloquear E4. 

Aunque la figura no lo muestre, la tabla de bloqueos 
debería mantener también un índice de identificadores 
de transacciones, de forma que fuese posible determi¬ 
nar de manera eficiente el conjunto de bloqueos que 
mantiene una transacción dada. 


E7 E23 



FIGURA 16.10. Tabla de bloqueos. 


El gestor de bloqueos procesa las solicitudes de la 
siguiente forma: 

• Cuando llega un mensaje de solicitud, añade un 
registro al final de la lista enlazada del elemento 
de datos, si la lista enlazada existe. En otro caso 
crea una nueva lista enlazada que tan sólo contie¬ 
ne el registro correspondiente a la solicitud. 

Siempre concede la primera solicitud de blo¬ 
queo sobre el elemento de datos. Pero si la tran¬ 
sacción solicita un bloqueo sobre un elemento 
sobre el cual ya se ha concedido un bloqueo, el 
gestor de bloqueos sólo concede la solicitud si es 
compatible con las solicitudes anteriores, y todas 
éstas ya se han concedido. En otro caso, la solici¬ 
tud tiene que esperar. 

• Cuando el gestor de bloqueos recibe un mensaje 
de desbloqueo de una transacción, borra el regis¬ 
tro para ese elemento de datos de la lista enlazada 
correspondiente a dicha transacción. Prueba el 
siguiente registro, si lo hay, como se describe en 
el párrafo anterior, para determinar si ahora se pue¬ 
de conceder dicha solicitud. Si se puede, el gestor 
de bloqueos concede la solicitud y procesa el 
siguiente registro, si lo hay, de forma similar, y así 
sucesivamente. 

• Si una transacción se intermmpe, el gestor de blo¬ 
queos borra cualquier solicitud en espera realiza¬ 
da por la transacción. Una vez que el sistema de 
base de datos ha realizado las acciones apropiadas 
para deshacer la transacción (véase el Apartado 
17.3), libera todos los bloqueos que mantenía la 
transacción abortada. 
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Este algoritmo garantiza que las solicitudes de blo¬ 
queo están libres de inanición, dado que una solicitud 
nunca se puede conceder mientras no se hayan conce¬ 
dido las solicitudes recibidas anteriormente. Más ade¬ 
lante, en el Apartado 16.6.3, se estudiará cómo detec¬ 
tar y manejar interbloqueos. El Apartado 18.2.1 describe 
una implementación alternativa —lina que utiliza memo¬ 
ria compartida en vez de paso de mensajes para la soli¬ 
citud y concesión de bloqueos. 

16.1.5. Protocolos basados en grafos 

Como se ha visto en el Apartado 16.1.3, en ausencia de 
información acerca de la forma en que se accede a los 
elementos de datos, el protocolo de bloqueo de dos 
fases es necesario y suficiente para asegurar la secuen- 
cialidad. Pero, si se desean desarrollar protocolos que 
no sean de dos fases, es necesario tener información 
adicional acerca de la forma en que cada transacción 
accede a la base de datos. Existen varios modelos que 
pueden ofrecer la información adicional, que difieren 
en la cantidad de información que proporcionan. El 
modelo más simple exige que se tenga un conocimiento 
previo acerca del orden en el cual se accede a los ele¬ 
mentos de la base de datos. Dada esta información es 
posible construir protocolos de bloqueo que no sean de 
dos fases pero que no obstante aseguren la secuencia- 
lidad. 

Para adquirir tal conocimiento previo, se impone un 
orden parcial —> sobre el conjunto D = {d l ,d 2 , ... , d n ¡ 
de todos los elementos de datos. Si d¡ —> c/ ; entonces 
toda transacción que acceda tanto a d¡ como a d¡ debe 
acceder a d¡ antes de acceder a d r Este orden parcial 
puede ser el resultado de la organización tanto lógica 
como física de los datos, o se puede imponer únicamente 
con motivo del control de concurrencia. 

El orden parcial implica que el conjunto D se pueda 
ver como un grafo dirigido acíclico denominado grafo 
de la base de datos. Para simplificar, este apartado cen¬ 
tra su atención sólo en aquellos grafos que son árboles 
con raíz. Se va a mostrar un protocolo simple llamado 
protocolo de árbol , el cual está restringido a utilizar sólo 
bloqueos exclusivos. En las notas bibliográficas se pro¬ 
porcionan referencias a otros protocolos basados en gra¬ 
fos más complejos. 

En el protocolo de árbol sólo se permite la instruc¬ 
ción de bloqueo bloquear-X. Cada transacción Ti pue¬ 
de bloquear un elemento de datos al menos una vez y 
debe seguir las siguientes reglas: 

1. El primer bloqueo de T¡ puede ser sobre cualquier 
elemento de datos. 

2. Posteriormente, T¡ puede bloquear un elemento 
de datos Q sólo si T¡ está bloqueando actualmen¬ 
te al padre de Q. 

3. Los elementos de datos bloqueados se pueden 
desbloquear en cualquier momento. 


4. T¡ no puede bloquear de nuevo un elemento de 
datos que ya haya bloqueado y desbloqueado ante¬ 
riormente. 

Todas las planificaciones que sean legales bajo el pro¬ 
tocolo de árbol son secuenciables en cuanto a conflic¬ 
tos. 

Para ilustrar este protocolo considérese el grafo de 
la base de datos de la Figura 16.11. Las cuatro transac¬ 
ciones siguientes siguen el protocolo de árbol sobre 
dicho grafo. Sólo se muestran las instrucciones de blo¬ 
queo y desbloqueo: 

7j 0 : bloquear-X(fí); bloquear-X(£); bloquear-X(D); 
desbloquear^); desbloquear(£); bloquear-X(G); 
desbloquear^); desbloquear(G). 

T n : bloquear-X(D); bloquear-X(//); desbloquear^); 
desbloquea^//). 

7j 2 : bloquear-X(S); bloquear-X(£); desbloquear(£); 
desbloquead/?). 

r 13 : bloquear-X(D); bloquear-X(//); desbloquear!/)); 
desbloquead//). 

En la Figura 16.12 se describe una planificación posi¬ 
ble en la que participan estas cuatro transacciones. Nóte¬ 
se que durante su ejecución, la transacción T l0 realiza 
bloqueos sobre dos subárboles disjuntos. 

Obsérvese que la planificación de la Figura 16.12 es 
secuenciable en cuanto a conflictos. Se puede demos¬ 
trar que el protocolo de árbol no sólo asegura la secuen- 
cialidad en cuanto a conflictos, sino que también ase¬ 
gura la ausencia de interbloqueos. 

El protocolo de árbol de la Figura 16.12 no asegura 
la recuperabilidad y la ausencia de cascadas. Para ase¬ 
gurar la recuperabilidad y la ausencia de cascadas, el 
protocolo se puede modificar para que no permita libe¬ 
rar bloqueos exclusivos hasta el final de la transacción. 
Mantener los bloqueos exclusivos hasta el final de la 
transacción reduce la concurrencia. Existe una alterna- 



FIGURA 16.11. Grafo de la base de datos con estructura 
de árbol. 
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E o 

Ti, 

T"l2 

T",3 

bloquear-X(B) 

bloquear-X(Z)) 

bloquear-X(//) 

desbloquear//)) 



bloquear-X(/?) 

bloquear-X(D) 

desbloquear!/?) 

desbloquear!/?) 

desbloquear!//) 

bloquear-X(B) 

bloquear-X(Z?) 


bloquear-X(G) 

desbloquead/)) 


desbloquead/?) 

desbloquear!/?) 

bloquear-X/D) 

bloquear-X(//) 

desbloquear(D) 

desbloquear!//) 

desbloquear(G) 





FIGURA 16.12. Planificación secuenciable bajo el protocolo de árbol. 


tiva que mejora la concurrencia, pero sólo asegura la 
recuperabilidad: para cada elemento de datos con una 
escritura no comprometida se registra qué transacción 
realizó la última escritura sobre el elemento de datos. 
Cada vez que una transacción T x realiza una lectura de 
un elemento de datos no comprometido, se registra una 
dependencia de compromiso de 7j en la transacción 
que realizó la última escritura sobre el elemento de datos. 
Entonces, no se permite que la transacción 7? se com¬ 
prometa hasta que todas las transacciones sobre las que 
tiene una dependencia de compromiso se comprome¬ 
tan. Si alguna de estas transacciones se intermmpe, tam¬ 
bién hay que interrumpir 7j. 

El protocolo de bloqueo de árbol tiene la ventaja 
sobre el protocolo de bloqueo de dos fases de que, a 
diferencia del bloqueo de dos fases, está libre de inter¬ 
bloqueos, así que no se necesitan retrocesos. El proto¬ 
colo de bloqueo de árbol tiene otra ventaja sobre el pro¬ 
tocolo de bloqueo de dos fases: que los desbloqueos se 
pueden producir antes. El hecho de desbloquear antes 
puede llevar a unos tiempos de espera menores y a un 
aumento de la concurrencia. 


Sin embargo, el protocolo tiene el inconveniente de 
que, en algunos casos, una transacción puede que ten¬ 
ga que bloquear elementos de datos a los que no acce¬ 
de. Por ejemplo, una transacción que tenga que acceder 
a los elementos de datos A y J en el grafo de la base de 
datos de la Figura 16.11, debe bloquear no sólo A y J 
sino también los elementos de datos B, D y H. Estos 
bloqueos adicionales producen un aumento del coste de 
los bloqueos, la posibilidad de tiempos de espera adi¬ 
cionales y un descenso potencial de la concurrencia. 
Además, sin un conocimiento previo de los elementos 
de datos que es necesario bloquear, las transacciones 
tienen que bloquear la raíz del árbol y esto puede redu¬ 
cir considerablemente la concurrencia. 

Para un conjunto de transacciones pueden existir pla¬ 
nificaciones secuenciables en cuanto a conflictos que 
no se pueden obtener por medio del protocolo de árbol. 
Realmente hay planificaciones que son posibles por 
medio del protocolo de bloqueo de dos fases que no son 
posibles por medio del protocolo de árbol y viceversa. 
En los ejercicios se exponen ejemplos de tales planifi¬ 
caciones. 


16.2. PROTOCOLOS BASADOS EN MARCAS TEMPORALES 


En los protocolos de bloqueo que se han descrito antes se 
determina el orden entre dos transacciones conflictivas en 
tiempo de ejecución a través del primer bloqueo que soli¬ 
citen ambas que traiga consigo modos incompatibles. Otro 


método para determinar el orden de secuencialidad es 
seleccionar previamente un orden entre las transacciones. 
El método más común para hacer esto es utilizar un esque¬ 
ma de ordenación por marcas temporales. 
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16.2.1. Marcas temporales 

A toda transacción Tj del sistema se le asocia una úni¬ 
ca marca temporal fijada, denotada por MT(Tj). El sis¬ 
tema de base de datos asigna esta marca temporal antes 
de que comience la ejecución de Tj. Si a la transacción 
Tj se le ha asignado la marca temporal MT(Tj) y una 
nueva transacción Tj entra en el sistema, entonces 
MT(Tj) < MT (Tj). Existen dos métodos simples para 
implementar este esquema: 

1. Usar el valor del reloj del sistema como marca 
temporal; es decir, la marca temporal de una tran¬ 
sacción es igual al valor del reloj en el momento 
en el que la transacción entra en el sistema. 

2. Usar un contador lógico que se incrementa cada 
vez que se asigna una nueva marca temporal; es 
decir, la marca temporal de una transacción 
es igual al valor del contador en el momento en 
el cual la transacción entra en el sistema. 

Las marcas temporales de las transacciones deter¬ 
minan el orden de secuencia. De este modo, si MT(Tj) 
< MT(Tj) entonces el sistema debe asegurar que toda 
planificación que produzca es equivalente a una plani¬ 
ficación secuencial en la cual la transacción Tj aparece 
antes que la transacción Tj. 

Para implementar este esquema se asocia a cada ele¬ 
mento de datos Q dos valores de marca temporal: 

• marca_temporal-E(0 denota la mayor marca 
temporal de todas las transacciones que ejecutan 
con éxito escrib¡r(0. 

• marca_temporal-L(0 denota la mayor marca 
temporal de todas las transacciones que ejecutan 
con éxito leer(0. 

Estas marcas temporales se actualizan cada vez que se 
ejecuta una nueva operación leer(Q) o escribir(Q). 

16.2.2. Protocolo de ordenación por marcas 
temporales 

El protocolo de ordenación por marcas temporales 

asegura que todas las operaciones leer y escribir con¬ 
flictivas se ejecutan en el orden de las marcas tempora¬ 
les. Este protocolo opera como sigue: 

1. Supóngase que la transacción Tj ejecuta leer(0. 

a. Si MT(Tj) < marea_tempora I -E( Q) entonces Tj 
necesita leer un valor de Q que ya se ha sobres¬ 
crito. Por tanto se rechaza la operación leer y 
Tj se retrocede. 

b. Si MT(Tj) > m are ate m pora I - E( 0 entonces se 
ejecuta la operación leer y marca_temporal- 
L(0 se asigna al máximo de marca_temporal- 

L(0 y de MT(Tj). 


2. Supóngase que la transacción Tj ejecuta escribir(0. 

a. Si MT(Tj) < m are ate m pora I - L( 0 ) entonces el 
valor de Q que produce Tj se necesita previa¬ 
mente y el sistema asume que dicho valor no 
se puede producir nunca. Por tanto, se rechaza 
la operación escribir y Tj se retrocede. 

b. Si MT(Tj) < marca tem pora I -E( 0 entonces Tj 
está intentando escribir un valor de Q obsole¬ 
to. Por tanto, se rechaza la operación escribir y 
Tj se retrocede. 

c. En otro caso se ejecuta la operación escribir y 
MT(Tj) se asigna a m are ate m pora I - E (0. 

A una transacción Tj que el esquema de control de con¬ 
currencia haya retrocedido como resultado de la ejecu¬ 
ción de una operación leer o escribir se le asigna una 
nueva marca temporal y se inicia de nuevo. 

Para ilustrar este protocolo considérense las tran¬ 
sacciones Tj 4 y Tj 5 . La transacción Tj 4 visualiza el con¬ 
tenido de las cuentas Ay B: 

Tj 4 : leer(TJ); 
leer(A); 

visualizará + B). 

La transacción Tj 5 transfiere 50 € de la cuenta A a la B 
y muestra después el contenido de ambas: 

Tj 5 : leer(TJ); 

B:=B- 50; 

escribir^); 

leer(A); 

A :=A + 50; 
escribir(A); 
visualizará + B). 

En las planificaciones actuales con el protocolo de mar¬ 
cas temporales se asume que a una transacción se le 
asigna una marca temporal inmediatamente antes de su 
primera instmcción. Así en la planificación 3 de la Figu¬ 
ra 16.13, MT(Tj 4 ) < MT(7 15 ) y la planificación con el 
protocolo de marcas temporales es posible. 

Nótese que la ejecución anterior puede obtenerse 
también con el protocolo de bloqueo de dos fases. Sin 
embargo, existen planificaciones que son posibles con 
el protocolo de bloqueo de dos fases que no lo son 
con el protocolo de marcas temporales y viceversa 
(véase el Ejercicio 16.20). 

El protocolo de ordenación por marcas temporales 
asegura la secuencialidad en cuanto a conflictos. Esta 
afirmación se deduce del hecho de que las operaciones 
conflictivas se procesan durante la ordenación de las 
marcas temporales. 

El protocolo asegura la ausencia de interbloqueos, 
ya que ninguna transacción tiene que esperar. 

Sin embargo, existe una posibilidad de inanición de 
las transacciones largas si una secuencia de transaccio- 
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T u 

Tib 

leer(B) 

leer(B) 

B--B-50 

escrlblr(B) 

leer(A) 

leer(A) 

visualizar(A + B) 

A := A + 50 
escribir(A) 
visualizar(A + B) 


FIGURA 16.13. Planificación 3. 


nes cortas conflictivas provoca reinicios repetidos de la 
transacción larga. Si se descubre que una transacción se 
está reiniciando de forma repetida, es necesario blo¬ 
quear las transacciones conflictivas de forma temporal 
para permitir que la transacción termine. 

El protocolo puede generar planificaciones no recu¬ 
perables. Sin embargo, se puede extender para produ¬ 
cir planificaciones recuperables de una de las siguien¬ 
tes formas: 

• La recuperabilidad y la ausencia de cascadas se 
pueden asegurar realizando todas las escrituras jun¬ 
tas al final de la transacción. Las escrituras tienen 
que ser atómicas en el siguiente sentido: mientras 
que las escrituras están en progreso, no se permi¬ 
te que ninguna transacción acceda a ninguno de 
los elementos de datos que se han escrito. 

• La recuperabilidad y la ausencia de cascadas tam¬ 
bién se pueden garantizar utilizando una forma 
limitada de bloqueo, por medio de la cual las lec¬ 
turas de los elementos no comprometidos se pos¬ 
ponen hasta que la transacción haya actualizado el 
elemento comprometido (véase el Ejercicio 16.22). 

• La recuperabilidad sola se puede asegurar reali¬ 
zando un seguimiento de las escrituras no com¬ 
prometidas y sólo permitiendo que una transac¬ 
ción Tj se comprometa después de que se 
comprometa cualquier transacción que escribió 
un valor que leyó 7j. Las dependencias de com¬ 
promiso, esbozadas en el Apartado 16.1.5, se pue¬ 
den utilizar para este propósito. 

16.2.3. Regla de escritura de Thomas 

Ahora se presenta una modificación del protocolo de 
ordenación por marcas temporales que permite una 
mayor concurrencia potencial que la que tiene el pro¬ 
tocolo del Apartado 16.2.2. Considérese la planificación 
4 de la Ligura 16.14 y apliqúese el protocolo de orde¬ 
nación por marcas temporales. Puesto que '/j 6 comien¬ 
za antes que T X1 se asume que MT(r i6 ) < MT(7\ 7 ). La 
operación leer(<2) de 7j 6 tiene éxito, así como la opera¬ 


Te 

T, 7 

leer(Q) 

escribirte) 

escribir(g) 


FIGURA 16.14. Planificación 4. 


ción escribir(<2) de T l7 . Cuando 7j f) intenta hacer su ope¬ 
ración escribir(<2) se encuentra con que MT(7j ft ) < mar- 
ca_temporal-E(<2), ya que marca_temporal-E(<2) = 
MT(7j 7 ). De este modo se rechaza la operación escri¬ 
bir^) de 7j ft y se debe retroceder la transacción. 

A pesar de que el protocolo de ordenación por mar¬ 
cas temporales exige el retroceso de la transacción T l6 , 
esto no es necesario. Como T X1 ya ha escrito Q, el valor 
que intenta escribir T l6 nunca se va a leer. Toda tran¬ 
sacción T¡ con MT(7j) < MT(T 17 ) que intente una ope¬ 
ración leer(<2) se retrocederá, ya que MT(r ; ) < mar- 
ca_temporal-E(<2). Toda transacción T¡ con MT(7j) > 
MT(T 17 ) debe leer el valor de Q que ha escrito T 17 en 
lugar del valor que ha escrito T l6 . 

Esta observación lleva a la versión modificada del 
protocolo de ordenación por marcas temporales en el 
cual se pueden ignorar las operaciones escribir obso¬ 
letas bajo ciertas circunstancias. Las reglas del pro¬ 
tocolo para las operaciones leer no sufren cambios. 
Sin embargo, las reglas del protocolo para las opera¬ 
ciones escribir son algo diferentes de las del protoco¬ 
lo de ordenación por marcas temporales del Aparta¬ 
do 16.2.2. 

La modificación al protocolo de ordenación por mar¬ 
cas temporales, denominada regla de escritura de Tilo¬ 
mas, es la siguiente. Supóngase que la transacción T¡ 
ejecuta escrib¡r(0. 

1. Si MT(T ; ) < marca_temporal-L(2), entonces el 
valor de Q que produce T¡ se necesita previamente 
y el sistema asume que dicho valor no se puede 
producir nunca. Por tanto, se rechaza la operación 
escribir y T¡ se retrocede. 

2. Si MT(T,) < m ar c a_t emp or al - E (Q), entonces T¡ 
está intentando escribir un valor de Q obsoleto. Por 
tanto se puede ignorar dicha operación escribir. 

3. En otro caso, se ejecuta la operación escribir y 
MT(T,) se asigna a m are ate m pora I -E( 0) ■ 

La diferencia entre las reglas anteriores y las del 
Apartado 16.2.2 está en la segunda regla. El protocolo 
de ordenación por marcas temporales exige que T¡ se 
retroceda si ejecuta escribir^) y MT(7j) < marca_tem- 
poral-E(<2). Sin embargo, ahora se ignora la instrucción 
escribir obsoleta en aquellos casos en los que MT(T,) > 
m are a te m pora I - L( 0). 

La regla de escritura de Thomas hace uso de la 
secuencialidad en cuanto a vistas borrando las opera¬ 
ciones escribir obsoletas de las transacciones que las 
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ejecutan. Esta modificación de las transacciones hace 
posible generar planificaciones que no serían posibles 
con otros protocolos que se han presentado en este capí¬ 
tulo. Por ejemplo, la planificación 4 de la Figura 16.14 
no es secuenciable en cuanto a conflictos y, por tanto, 
no es posible con cualquiera de los dos bloqueos de dos 


fases, con el protocolo de árbol o con el protocolo de 
ordenación por marcas temporales. Con la regla de escri¬ 
tura de Thomas se ignoraría la operación escribir(<2) de 
Tj 6 . El resultado es una planificación que es equivalen¬ 
te en cuanto a vistas a la planificación secuencial 


16.3. PROTOCOLOS BASADOS EN VALIDACIÓN 


En aquellos casos en que la mayoría de las transac¬ 
ciones son de sólo lectura, la tasa de conflictos entre 
las transacciones puede ser baja. Así, muchas de esas 
transacciones, si se ejecutasen sin la supervisión de 
un esquema de control de concurrencia, llevarían no 
obstante al sistema a un estado consistente. Un esque¬ 
ma de control de concurrencia impone una sobrecar¬ 
ga en la ejecución de código y un posible retardo en 
las transacciones. Sería aconsejable utilizar otro esque¬ 
ma alternativo que impusiera menos sobrecarga. La 
dificultad de reducir la sobrecarga está en que no se 
conocen de antemano las transacciones que estarán 
involucradas en un conflicto. Para obtener dicho cono¬ 
cimiento se necesita un esquema para supervisar el 
sistema. 

Se asume que cada transacción Tj se ejecuta en dos 
o tres fases diferentes durante su tiempo de vida depen¬ 
diendo de si es una transacción de sólo lectura o una de 
actualización. Las fases son, en orden, 

1. Fase de lectura. Durante esta fase tiene lugar la 
ejecución de la transacción Tj. Se leen los valo¬ 
res de varios elementos de datos y se almacenan 
en variables locales de Tj. Todas las operaciones 
escribir se realizan sobre las variables locales tem¬ 
porales sin actualizar la base de datos actual. 

2. Fase de validación. La transacción Tj realiza 
una prueba de validación para determinar si pue¬ 
de copiar a la base de datos las variables loca¬ 
les temporales que tienen los resultados de las 
operaciones escribir sin causar una violación de 
la secuencialidad. 

3. Fase de escritura. Si la transacción Tj tiene éxi¬ 
to en la validación (paso 2) entonces las actuali¬ 
zaciones reales se aplican a la base de datos. En 
otro caso, Tj se retrocede. 

Cada transacción debe pasar por las tres fases y en el 
orden que se muestra. Sin embargo, se pueden entrela¬ 
zar las tres fases de la ejecución concurrente de las tran¬ 
sacciones. 

Para realizar la pmeba de validación se necesita cono¬ 
cer el momento en que tienen lugar las distintas fases 
de las transacciones Tj. Se asociarán por tanto tres mar¬ 
cas temporales distintas a la transacción Tj: 


1. Inicio(Tj), momento en el cual Tj comienza su eje¬ 
cución. 

2. Validación(Tj), momento en el cual Tj termina su 
fase de lectura y comienza su fase de validación. 

3. Fin(Tj), momento en el cual Tj termina su fase de 
escritura. 

Se determina el orden de secuencialidad a través 
de la técnica de la ordenación por marcas temporales 
utilizando el valor de la marca temporal Validación(Tj). 
De este modo, el valor MT(Tj) = Validación(Tj) y, si 
MT(Tj) < MT(Tj), entonces toda planificación que se 
produzca debe ser equivalente a una planificación 
secuencial en la cual la transacción Tj aparezca antes 
que la transacción Tj.. La razón por la que se ha elegi¬ 
do Validación(7j) como marca temporal de la tran¬ 
sacción Tj, en lugar de Inicio(7j), es porque se puede 
esperar un tiempo de respuesta más rápido, dado que 
la tasa de conflictos entre transacciones es realmente 
bajo. 

La comprobación de validación para la transacción 
Tj exige que, para toda transacción 7j con MT(7j) < 
MT(Tj), se cumplan una de las dos condiciones siguien¬ 
tes: 

1. Fin(7j) < Inicio(Tj). Puesto que T¡ completa su eje¬ 
cución antes de que comience Tj, el orden de 
secuencialidad se mantiene realmente. 

2. El conjunto de todos los elementos de datos que 
escribe Tj tiene intersección vacía con el conjun¬ 
to de elementos de datos que lee Tj, y Tj comple¬ 
ta su fase de escritura antes de que Tj comience 
su fase de validación (Inicio(Tj) < Fin(Tj) < Vali¬ 
dación^)). Esta condición asegura que las escri¬ 
turas de Tj y Tj no se supeipongan. Puesto que las 
escrituras de Tj no afectan a la lectura de Tj, y pues¬ 
to que Tj no puede afectar a la lectura de Tj, el 
orden de secuencialidad se mantiene realmente. 

Como ejemplo considérense de nuevo las transac¬ 
ciones Tj 4 y Tj 5 . Supóngase que MT(Tj 4 ) < MT(Tj 5 ). 
Entonces la fase de validación tiene éxito y produce la 
planificación 5, la cual se describe en la Figura 16.15. 
Nótese que las escrituras a las variables actuales se rea¬ 
lizan sólo después de la fase de validación de 7j 5 . Así, 
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Tu 

Es 

leer (5) 

leer(B) 
B-B- 50 
leer(A) 

A := A + 50 

leer(A) 

{ validar) 
visualizar(A +B) 

( validar) 

escribirte?) 

escribir(A) 


FIGURA 16.15. Planificación 5 producida usando validación. 

r i4 lee los valores anteriores de B y A y la planificación 
es secuenciable. 

El esquema de validación evita automáticamente 
los retrocesos en cascada, ya que las escrituras reales 


tienen lugar sólo después de que la transacción que 
ejecuta la escritura se haya comprometido. Sin embar¬ 
go, existe una posibilidad de inanición de las transac¬ 
ciones largas debido a una secuencia de transacciones 
cortas conflictivas que provoca reinicios repetidos de 
la transacción larga. Para evitar la inanición es ne¬ 
cesario bloquear las transacciones conflictivas de for¬ 
ma temporal para permitir que la transacción larga ter¬ 
mine. 

Este esquema de validación se denomina esquema 
control de concurrencia optimista, dado que las 
transacciones se ejecutan de forma optimista, asu¬ 
miendo que serán capaces de finalizar la ejecución y 
validar al final. En cambio, los bloqueos y la orde¬ 
nación por marcas temporales son pesimistas, debi¬ 
do a que fuerzan una espera o un retroceso cada vez 
que se detecta un conflicto, aún cuando existe una 
posibilidad de que la planificación sea secuenciable 
en cuanto a conflictos. 


16.4. GR ANULAR IDAD MÚLTIPLE 


En los esquemas de control de concurrencia que se han 
descrito antes se ha tomado cada elemento de datos indi¬ 
vidual como la unidad sobre la cual se producía la sin¬ 
cronización. 

Sin embargo, hay circunstancias en las que puede ser 
conveniente agrupar varios elementos de datos y tra¬ 
tarlos como una unidad individual de sincronización. 
Por ejemplo, si la transacción T¡ tiene que acceder a toda 
la base de datos y se usa un protocolo de bloqueo, enton¬ 
ces T¡ debe bloquear cada elemento de la base de datos. 
Ejecutar estos bloqueos produce claramente un consu¬ 
mo de tiempo. Sería mejor que T¡ pudiera realizar una 
única petición de bloqueo para bloquear toda la base de 
datos. Por otro lado, si la transacción Ti necesita acce¬ 
der sólo a unos cuantos datos no sería necesario blo¬ 
quear toda la base de datos, ya que en ese caso se per¬ 
dería la concurrencia. 

Lo que se necesita es un mecanismo que permita al 
sistema definir múltiples niveles de granularidad. Se 
puede hacer uno permitiendo que los elementos de 
datos sean de varios tamaños y definiendo una jerar¬ 
quía de granularidades de los datos, en la cual las gra- 
nularidades pequeñas están anidadas en otras más 
grandes. Una jerarquía tal se puede representar gráfi¬ 
camente como un árbol. Nótese que el árbol que se usa 
aquí es significativamente distinto del que se usaba en 
el protocolo de árbol (Apartado 16.1.5). Un nodo inter¬ 
no del árbol de granularidad múltiple representa los 
datos que se asocian con sus descendientes. En el pro¬ 
tocolo de árbol cada nodo es un elemento de datos 
independiente. 

Como ejemplo considérese el árbol de la Figura 
16.16, el cual consiste en cuatro niveles de nodos. El 


nivel superior representa toda la base de datos. Después 
de éste están los nodos de tipo zona; la base de datos 
consiste en estas zonas exactamente. Cada zona tiene 
nodos de tipo archivo como hijos. Cada zona contiene 
exactamente aquellos archivos que sean sus nodos lujos. 
Ningún archivo está en más de una zona. Finalmente 
cada archivo tiene nodos de tipo registro. Como antes, 
un archivo consiste exactamente en aquellos registros 
que sean sus nodos hijos y ningún registro puede estar 
presente en más de un archivo. 

Se puede bloquear individualmente cada nodo del 
árbol. Como ya se hizo en el protocolo de bloqueo de 
dos fases, se van a usar los modos de bloqueo com¬ 
partido y exclusivo. Cuando una transacción bloquea 
un nodo, tanto en modo compartido como exclusivo, 
también bloquea todos los descendientes de ese nodo 
con el mismo modo de bloqueo. Por ejemplo, si la 
transacción T¡ bloquea explícitamente el archivo A c 
de la Figura 16.16 en modo exclusivo, entonces blo¬ 
quea implícitamente en modo exclusivo todos los 
registros que pertenecen a dicho archivo. No es nece¬ 
sario que bloquee explícitamente cada registro indi¬ 
vidual de A c . 

Supóngase que la transacción T- quiere bloquear el 
registro r bf¡ del archivo A b . Puesto que Ti ha bloqueado 
A h explícitamente, se entiende que también se bloquea 
i\ (implícitamente). Pero cuando T realiza una petición 
de bloqueo sobre r b/¡ , \r bó no está bloqueado explícita¬ 
mente! ¿Cómo puede determinar el sistema si T- puede 
bloquear r h/ ‘! T ; debe recorrer el árbol desde la raíz has¬ 
ta el nodo r bó . Si cualquier nodo del camino está blo¬ 
queado en un modo incompatible entonces hay que retra¬ 
sar T¡. 
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FIGURA 16.16. Jerarquía de granularidad. 


Supóngase ahora que la transacción T k quiere blo¬ 
quear toda la base de datos. Para hacer esto debe 
bloquear simplemente la raíz de la jerarquía. Nótese, sin 
embargo, que T k no tendrá éxito al bloquear el nodo raíz, 
ya que T¡ posee un bloqueo sobre parte del árbol (en con¬ 
creto sobre el archivo A,,). ¿Pero cómo determina el sis¬ 
tema si se puede bloquear el nodo raíz? Una posibilidad 
es buscar en todo el árbol. Sin embargo esta solución 
anula el propósito del esquema de bloqueo de granula¬ 
ridad múltiple. Un modo más eficiente de obtener este 
conocimiento es introducir una nueva clase de modo de 
bloqueo que se denomina modo de bloqueo intencio¬ 
nal. Si un nodo se bloquea en modo intencional se está 
haciendo un bloqueo explícito en un nivel inferior del 
árbol (es decir, en una granularidad más fina). Los blo¬ 
queos intencionales se colocan en todos los ascendientes 
de un nodo antes de bloquearlo explícitamente. Así, no 
es necesario que una transacción busque en todo el árbol 
para determinar si puede bloquear un nodo con éxito. 
Una transacción que quiera bloquear un nodo —por 
ejemplo Q — debe recorrer el camino en el árbol desde 
la raíz hasta Q. Durante el recorrido del árbol la 
transacción bloquea los distintos nodos en un modo 
intencional. 

Hay un modo intencional asociado al modo com¬ 
partido y hay otro asociado al modo exclusivo. Si un 
nodo se bloquea en modo ¡ntencional-compartido 
(IC) se realiza un bloqueo explícito en un nivel infe¬ 
rior del árbol, pero sólo con bloqueos en modo com¬ 
partido. De forma similar, si se bloquea un nodo en 
modo intencional-exclusivo (IX) entonces el bloqueo 
explícito se hace en un nivel inferior con bloqueos en 
modo exclusivo o en modo compartido. Finalmente, 
si se bloquea un nodo en modo intencional-exclusi- 
vo y compartido (IXC) el subárbol cuya raíz es ese 
nodo se bloquea explícitamente en modo exclusivo, y 
dicho bloqueo explícito se produce en un nivel infe¬ 
rior con bloqueos en modo exclusivo. La función de 
compatibilidad para estos modos de bloqueo se pre¬ 
senta en la Figura 16.17. 

El protocolo de bloqueo de granularidad múlti¬ 
ple siguiente asegura la secuencialidad. Cada transac¬ 


ción T¡ puede bloquear un nodo Q usando las reglas 
siguientes: 

1. Debe observar la función de compatibilidad de 
bloqueos de la Figura 16.17. 

2. Debe bloquear la raíz del árbol en primer lugar y 
puede bloquearla en cualquier modo. 

3. Puede bloquear un nodo Q en modo C o IC sólo 
si está bloqueando actualmente al padre de Q en 
modo IX o IC. 

4. Puede bloquear un nodo Q en modo X, IXC o IX 
sólo si está bloqueando actualmente al padre de 
Q en modo IX o IXC. 

5. Puede bloquear un nodo sólo si no ha desblo¬ 
queado previamente ningún nodo (es decir, T¡ es 
de dos fases). 

6. Puede desbloquear un nodo Q sólo si no ha blo¬ 
queado a ninguno de los hijos de Q. 

Obsérvese que en el protocolo de granularidad múlti¬ 
ple es necesario que se adquieran los bloqueos en orden 
descendente (de la raíz a las hojas), y que se liberen en 
orden ascendente (de las hojas a la raíz). 

Para ilustrar este protocolo considérese el árbol de 
la Figura 16.16 y las transacciones siguientes: 

• Supóngase que la transacción Yj s lee el registro r ü2 
del archivo A a . Entonces 7j x necesita bloquear la 
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FIGURA 16.17. Matriz de compatibilidad. 


395 

















FUNDAMENTOS DE BASES DE DATOS 


base de datos, la zona Z, y A a en modo IC (y en este 
orden) y finalmente debe bloquear r„ 2 en modo C. 

• Supóngase que la transacción 7j 9 modifica el regis¬ 
tro r ag del archivo A a . Entonces T l9 necesita blo¬ 
quear la base de datos, la zona Z, y el archivo A a 
en modo IX y finalmente debe bloquear r ag en 
modo X. 

• Supóngase que la transacción T 20 lee todos los 
registros del archivo A a . Entonces, T 20 necesita 
bloquear la base de datos y la zona Z y (y ello en 
este orden) en modo IC y finalmente debe blo¬ 
quear A a en modo C. 

• Supóngase que la transacción T 2l lee toda la base 
de datos. Puede hacer esto una vez que bloquee la 
base de datos en modo C. 

Se observa que las transacciones T iS , T 20 y T 2l pueden 
acceder concurrentemente a la base de datos. La tran¬ 
sacción T ig se puede ejecutar concurrentemente con Yj x , 
pero no con T 10 ni con T 21 . 


Este protocolo permite la concurrencia y reduce la 
sobrecarga de bloqueos. Es particularmente útil en las 
aplicaciones con una mezcla de 

• Transacciones cortas que sólo acceden a algunos 
elementos de datos. 

• Transacciones largas que producen informes a par¬ 
tir de un archivo completo o un conjunto de archi¬ 
vos. 

Existe un protocolo de bloqueo similar que es apli¬ 
cable a sistemas de bases de datos en los cuales las gra- 
nularidades de los datos se organizan en forma de gra- 
fo dirigido acíclico. Véanse las notas bibliográficas para 
obtener referencias adicionales. En este protocolo son 
posibles los interbloqueos, al igual que en los protoco¬ 
los de bloqueo de dos fases. Existen técnicas para re¬ 
ducir la frecuencia de interbloqueos en el protocolo de 
granularidad múltiple y también para eliminar los inter¬ 
bloqueos completamente. Se hace referencia a estas téc¬ 
nicas en las notas bibliográficas. 


16.5. ESQUEMAS MULTIVERSIÓN 


Los esquemas de control de concurrencia que se han des¬ 
crito anteriormente aseguran la secuencialidad o bien 
retrasando una operación o bien abortando la transac¬ 
ción que realiza la operación. Por ejemplo, una opera¬ 
ción leer se puede retrasar porque todavía no se haya 
escrito el valor apropiado; o se puede rechazar (es decir, 
la transacción que la realiza debe abortarse) porque se 
haya sobrescrito el valor que supuestamente se iba a leer. 
Se podrían evitar estos problemas si se mantuvieran en 
el sistema copias anteriores de cada elemento de datos. 

En los esquemas de control de concurrencia mul- 
tiversión, cada operación escribir((2) crea una nueva 
versión de Q. Cuando se realiza una operación leer(Q) 
el gestor de control de concurrencia elige una de las ver¬ 
siones de Q que se va a leer. El esquema de control de 
concurrencia debe asegurar que la elección de la ver¬ 
sión que se va a leer se haga de tal manera que asegure 
la secuencialidad. Así mismo es crucial, por motivos de 
rendimiento, que una transacción sea capaz de deter¬ 
minar rápida y fácilmente la versión del elemento de 
datos que se va a leer. 

16.5.1. Ordenación por marcas temporales 
multiversión 

La técnica más frecuentemente utilizada en los esque¬ 
mas multiversión es la de las marcas temporales. A cada 
transacción T¡ del sistema se le asocia una única marca 
temporal estática que se denota MT(T,). El sistema de 
bases de datos asigna dicha marca temporal antes de 
que la transacción comience su ejecución, como se ha 
descrito en el Apartado 16.2. 


A cada elemento de datos Q se el asocia una secuen¬ 
cia de versiones <Q { , Q 2 , ... , Q m > . Cada versión Q k 
contiene tres campos: 

• contenido es el valor de la versión Q k . 

• marcatcm poral-EiQ^) es la marca temporal de 
la transacción que haya creado la versión Q k . 

• marca^emporal-LíQ,;.) es la mayor marca tem¬ 
poral de todas las transacciones que hayan leído 
con éxito la versión Q k . 

Una transacción —por ejemplo, T¡ — crea una nue¬ 
va versión Q k del elemento de datos Q realizando la ope¬ 
ración escribí r(<2). El campo contenido de la versión tie¬ 
ne el valor que ha escrito T¡. El sistema oficializa la 
marca_temporal-E y marca_temporal-L con MT(r,). El 
valor marca_temporal-L se actualiza cada vez que una 
transacción lee el contenido de Q k y marca_tempo- 
ral-L (Q k ) < MT(7}). 

El esquema de marcas temporales multiversión 

que se muestra a continuación asegura la secuenciali¬ 
dad. El esquema opera como sigue. Supóngase que la 
transacción T¡ realiza una operación leer(<2) o escri¬ 
bir^). Sea Q k la versión de Q cuya marca temporal de 
escritura es la mayor marca temporal menor o igual que 
MTCT,). 

1. Si la transacción T¡ ejecuta leer(Q), entonces el valor 
que se devuelve es el contenido de la versión Q k . 

2. Si la transacción T¡ ejecuta escribir(Q) y si MT(T,) 
< marcatemporal -L( Q k ), entonces la transacción 


396 






CAPÍTULO 16 CONTROL DE CONCURRENCIA 


T¡ se retrocede. Si no, si MT(r ; ) = marca_tempo- 
ral-E (Q k ) se sobrescribe el contenido de Q k , y en 
otro caso se crea una nueva versión de Q. 

La justificación de la regla 1 es clara. Una transac¬ 
ción lee la versión más reciente que viene antes de ella 
en el tiempo. La segunda regla fuerza a que se aborte 
una transacción que realice una escritura «demasiado 
tarde». Con más precisión, si T¡ intenta escribir una ver¬ 
sión que alguna otra transacción haya leído, entonces 
no se puede permitir que dicha escritura tenga éxito. 

Las versiones que ya no se necesitan se borran basán¬ 
dose en la regla siguiente. Supóngase que hay dos ver¬ 
siones, Q k y Q r de un elemento de datos y que ambas 
tienen marca_temporal-E menor que la marca tempo¬ 
ral de la transacción más antigua en el sistema. Enton¬ 
ces no se volverá a usar la versión más antigua de Q k y 
Qj y se puede borrar. 

El esquema de ordenación por marcas temporales 
multiversión tiene la propiedad deseable de que nunca 
falla una petición de lectura y nunca tiene que esperar. 
En sistemas de bases de datos típicos, en los cuales la 
lectura es una operación mucho más frecuente que la 
escritura, esta ventaja puede tener un mayor significa¬ 
do práctico. 

Este esquema, sin embargo, tiene dos propiedades 
no deseables. En primer lugar, la lectura de un elemen¬ 
to de datos necesita también la actualización del cam¬ 
po marca_temporal-L, lo que tiene como resultado dos 
accesos potenciales al disco en lugar de uno. En segun¬ 
do lugar, los conflictos entre las transacciones se resuel¬ 
ven por medio de retrocesos en lugar de esperas. Esta 
alternativa puede ser costosa. En el Apartado 16.5.2 se 
describe un algoritmo que evita este problema. 

Este esquema de ordenación por marcas temporales 
multiversión no asegura la recuperabilidad y la ausen¬ 
cia de cascadas. Se puede extender de la misma forma 
que el esquema de ordenación por marcas temporales 
básico, para hacerlo recuperable y sin cascadas. 

16.5.2. Bloqueo de dos fases multiversión 

El protocolo de bloqueo de dos fases multiversión 

intenta combinar las ventajas del control de concurren¬ 
cia multiversión con las ventajas del bloqueo de dos 
fases. Este protocolo distingue entre transacciones de 
sólo lectura y transacciones de actualización. 

Las transacciones de actualización realizan un blo¬ 
queo de dos fases riguroso; es decir, mantienen todos 
los bloqueos hasta el final de la transacción. Así, se pue¬ 
den secuenciar según su orden de terminación. Cada 


elemento de datos tiene una única marca temporal. La 
marca temporal no es en este caso una marca temporal 
basada en un reloj real, sino que es un contador, que se 
denomina contador_mt, que se incrementa durante el 
procesamiento del compromiso. 

A las transacciones de sólo lectura se les asigna una 
marca temporal leyendo el valor actual de contador_mt 
antes de que comiencen su ejecución; para realizar las 
lecturas siguen el protocolo de ordenación por marcas 
temporales multiversión. Así, cuando una transacción 
de sólo lectura T¡ ejecuta leer(<2), el valor que se devuel¬ 
ve es el contenido de la versión con la mayor marca tem¬ 
poral menor que MT(r,). 

Cuando una transacción de actualización lee un ele¬ 
mento obtiene un bloqueo compartido sobre él y lee la 
versión más reciente de dicho elemento de datos. Cuan¬ 
do una transacción de actualización quiere escribir un 
elemento, obtiene primero un bloqueo exclusivo sobre 
el elemento, y luego crea una nueva versión del ele¬ 
mento de datos. La escritura se realiza sobre la nueva 
versión y la marca temporal de la nueva versión tiene 
inicialmente el valor oo, el cual es mayor que el de cual¬ 
quier marca temporal posible. 

Una vez que la transacción T¡ ha completado sus 
acciones realiza el procesamiento del compromiso 
como sigue: en primer lugar, T¡ asigna la marca tem¬ 
poral de todas las versiones que ha creado al valor de 
contador_mt más 1; después T¡ incrementa conta- 
dor_mt en 1. Sólo se permite que realice el procesa¬ 
miento del compromiso a una transacción de actuali¬ 
zación a la vez. 

Como resultado, las transacciones que comiencen 
después de que T¡ incremente contador_mt observarán 
los valores que T¡ ha actualizado, mientras que aquellas 
que comiencen antes de que T¡ incremente contador_mt 
observarán los valores anteriores a la actualización de 
T¡. En ambos casos las transacciones de sólo lectura no 
tienen que esperar nunca por los bloqueos. El bloqueo 
de dos fases multiversión también asegura que las pla¬ 
nificaciones son recuperables y sin cascadas. 

Las versiones se borran de forma similar a la utili¬ 
zada en la ordenación por marcas temporales multiver¬ 
sión. Supóngase que hay dos versiones, Q k y Q r de un 
elemento de datos y que ambas versiones tienen una 
marca temporal menor que la de la transacción de sólo 
lectura más antigua del sistema. Entonces la versión 
más antigua de Q k y Q¡ no se volverá a utilizar y se pue¬ 
de borrar. 

El bloqueo de dos fases multiversión o variaciones 
de éste se usan en algunos sistemas de bases de datos 
comerciales. 
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16.6. TRATAMIENTO DE INTERBLOQUEOS 


Un sistema está en estado de interbloqueo si existe un 
conjunto de transacciones tal que toda transacción del 
conjunto está esperando a otra transacción del conjun¬ 
to. Con mayor precisión, existe un conjunto de tran¬ 
sacciones en espera { T 0 , T x , Yj, ¡ tal que T 0 está espe¬ 
rando a un elemento de datos que posee T x , y T 2 está 
esperando a un elemento de datos que posee T 2 , y ..., y 
7j, ! está esperando a un elemento de datos que posee 
T n . y T„ está esperando a un elemento que posee 7 0 . En 
tal situación ninguna de las transacciones puede pro¬ 
gresar. 

El único remedio a esta situación no deseada es que 
el sistema invoque alguna acción drástica, como retro¬ 
ceder alguna de las transacciones involucradas en el 
interbloqueo. El retroceso de una transacción puede ser 
parcial: esto es, se puede retroceder una transacción has¬ 
ta el punto donde obtuvo un bloqueo cuya liberación 
resuelve el interbloqueo. 

Existen dos métodos principales para tratar el pro¬ 
blema de los interbloqueos. Se puede utilizar un pro¬ 
tocolo de prevención de interbloqueos para asegurar 
que el sistema nunca llega a un estado de interbloqueo. 
De forma alternativa se puede permitir que el sistema 
llegue a un estado de interbloqueo, y tratar de recupe¬ 
rarse después a través de un esquema de detección y 
recuperación de interbloqueos. Como se verá a con¬ 
tinuación, ambos pueden provocar retroceso de las tran¬ 
sacciones. La prevención se usa normalmente cuando 
la probabilidad de que el sistema llegue a un estado de 
interbloqueo es relativamente alta; en otro caso es más 
eficiente usar la detección y recuperación. 

Nótese que el esquema de detección y recuperación 
necesita una sobrecarga que incluye no sólo el coste en 
tiempo de ejecución para mantener la información nece¬ 
saria para ejecutar el algoritmo de detección, sino tam¬ 
bién las pérdidas potenciales inherentes a la recupera¬ 
ción de un interbloqueo. 

16.6.1. Prevención de interbloqueos 

Existen dos enfoques a la prevención de interbloqueos. 
Un enfoque asegura que no puede haber esperas cícli¬ 
cas ordenando las peticiones de bloqueo o exigiendo 
que todos los bloqueos se adquieran juntos. El otro enfo¬ 
que es más cercano a la recuperación de interbloqueos 
y realiza retrocesos de las transacciones en lugar de espe¬ 
rar un bloqueo, siempre que el bloqueo pueda llevar 
potencialmente a un interbloqueo. 

El esquema más simple para la primera aproxima¬ 
ción exige que cada transacción bloquee todos sus ele¬ 
mentos de datos antes de comenzar su ejecución. Ade¬ 
más, o bien se bloquean todos en un paso o ninguno de 
ellos se bloquea. Este protocolo tiene dos inconvenien¬ 
tes principales: 1) a menudo es difícil predecir, antes de 
que comience la transacción, cuáles son los elementos 


de datos que es necesario bloquear; 2) la utilización de 
elementos de datos puede ser muy baja, ya que muchos 
de los elementos de datos pueden estar bloqueados pero 
sin usar durante mucho tiempo. 

Otro esquema para prevenir interbloqueos consiste en 
imponer un orden parcial a todos los elementos de datos 
y exigir que una transacción bloquee un elemento de 
datos sólo en el orden que especifica dicho orden par¬ 
cial. Se ha visto un esquema así en el protocolo de árbol, 
que usa una ordenación parcial de los elementos de datos. 

Una variante a esta aproximación es utilizar un orden 
total de los elementos de datos, en conjunción con el 
bloqueo de dos fases. Una vez que una transacción ha 
bloqueado un elemento en particular, no puede solici¬ 
tar bloqueos sobre elementos que preceden a dicho ele¬ 
mento en la ordenación. Este esquema es fácil de imple- 
mentar siempre que el conjunto de los elementos de 
datos a los que accede una transacción se conozca cuan¬ 
do la transacción comienza la ejecución. No hay nece¬ 
sidad de cambiar el sistema de control de concurrencia 
subyacente si se utiliza bloqueo de dos fases: todo lo 
que hace falta es asegurar que los bloqueos se solicitan 
en el orden adecuado. 

La segunda aproximación para prevenir interblo¬ 
queos consiste en utilizar expropiación y retrocesos de 
transacciones. En la expropiación, cuando la transac¬ 
ción T 2 solicita un bloqueo que la transacción Yj posee, 
el bloqueo concedido a T x debe expropiarse retroce¬ 
diendo T l y concediéndolo a continuación a T 2 . Para 
controlar la expropiación se asigna una marca tempo¬ 
ral única a cada transacción. El sistema usa estas mar¬ 
cas temporales sólo para decidir si una transacción debe 
esperar o retroceder. Para el control de concurrencia se 
sigue usando el bloqueo. Si una transacción se retroce¬ 
de mantiene su marca temporal antigua cuando vuelva 
a comenzar. Se han propuesto dos esquemas de pre¬ 
vención de interbloqueos que usan marcas temporales: 

1. El esquema esperar-morir está basado en una 
técnica sin expropiación. Cuando la transacción 
Yj solicita un elemento de datos que posee actual¬ 
mente Tj, Yj puede esperar sólo si tiene una mar¬ 
ca temporal más pequeña que la de Yj (es decir, 
Yj es anterior a Yj). En otro caso Yj se retrocede 
(muere). Por ejemplo, supóngase que las tran¬ 
sacciones T 22 , T 23 y T 24 tienen marcas temporales 
5, 10 y 15 respectivamente. Si T 22 solicita un ele¬ 
mento de datos que posee T 23 entonces T 22 tiene 
que esperar. Si T 14 solicita un elemento de datos 
que posee T 23 entonces T 24 se retrocede. 

2. El esquema herir-esperar está basado en una téc¬ 
nica de expropiación. Es el opuesto del esquema 
esperar-morir. Cuando la transacción Yj solicita un 
elemento de datos que posee actualmente Yj, Yj pue- 
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de esperar sólo si tiene una marca temporal mayor 
que la de T¡ (es decir, T¡ es más reciente que T). En 
otro caso Y ; se retrocede (T¡ hiere a T-). Volviendo 
al ejemplo anterior con las transacciones T 22 , T 23 y 
r 24 , si T 22 solicita un elemento de datos que posee 
T 23 entonces se expropia este elemento de datos y 
T 23 se retrocede. Si T 24 solicita el elemento de datos 
que posee T 23 entonces T 24 debe esperar. 

Siempre que se retrocedan las transacciones, es 
importante asegurarse de que no exista inanición, es 
decir, ninguna transacción se retrocede repetidamente 
y nunca se le permite progresar. 

Tanto el esquema herir-esperar como el esperar-morir 
impiden la inanición: en todo momento hay una tran¬ 
sacción con la menor marca temporal. Dicha transac¬ 
ción no se puede retroceder en ninguno de los dos esque¬ 
mas. Puesto que las marcas temporales siempre se 
incrementan, y puesto que no se asignan a las transac¬ 
ciones nuevas marcas temporales cuando se retroceden, 
una transacción que se retrocede tendrá finalmente la 
menor marca temporal. De este modo no se retrocede¬ 
rá de nuevo. 

Sin embargo, existen algunas diferencias en el modo 
en que operan estos dos esquemas. 

• En el esquema esperar-morir una transacción más 
antigua debe esperar a que una más reciente libere 
sus elementos de datos. Así, cuanto más antigua se 
vuelve una transacción más tiende a esperar. Por el 
contrario, en el esquema herir-esperar, una transac¬ 
ción más antigua nunca espera a una más reciente. 

• En el esquema esperar-morir, si la transacción T¡ 
muere y se retrocede a causa de que ha solicitado 
un elemento de datos que posee la transacción 7’ ; , 
entonces T¡ puede volver a realizar la misma secuen¬ 
cia de peticiones cuando vuelva a comenzar. Si 7j 
posee todavía el elemento de datos, entonces T¡ 
morirá de nuevo. De este modo T¡ morirá varias 
veces hasta que adquiera el elemento de datos que 
necesita. Compárese esta secuencia de sucesos con 
la que ocurre en el esquema herir-esperar. La tran¬ 
sacción T¡ está herida y se retrocede porque 7j soli¬ 
cita un elemento de datos que posee. Cuando vuel¬ 
ve a comenzar T¡ y solicita el elemento de datos que 
ahora posee Y’ ; , T¡ espera. De este modo puede haber 
menos retrocesos en el esquema herir-esperar. 

El principal problema de cualquiera de estos dos 
esquemas es que se pueden dar retrocesos innecesarios. 

16.6.2. Esquemas basados en límite de tiempo 

Otro enfoque simple al tratamiento de interbloqueos se 
basa en bloqueos con límite de tiempo. En este enfo¬ 
que una transacción que haya solicitado un bloqueo 
espera por lo menos durante un intervalo de tiempo espe¬ 
cificado. Si no se concede el bloqueo en ese tiempo, se 


dice que la transacción está fuera de tiempo y ella mis¬ 
ma se retrocede y vuelve a comenzar. Si de hecho había 
un interbloqueo, una o varias de las transacciones invo¬ 
lucradas en dicho interbloqueo estarán fuera de tiempo 
y se retrocederán, lo que permitirá continuar a las demás. 
Este esquema se encuentra en un lugar entre la preven¬ 
ción de interbloqueos, donde nunca puede haber un 
interbloqueo, y la detección y recuperación, las cuales 
se describen en el Apartado 16.6.3. 

El esquema de límite de tiempo es particularmente 
fácil de implementar y funciona bien si las transaccio¬ 
nes son cortas y, si son largas, las esperas deben de ser 
a causa de los interbloqueos. Sin embargo, es difícil en 
general decidir cuánto debe esperar una transacción para 
que esté fuera de tiempo. Esperas demasiado largas pro¬ 
vocan retardos innecesarios una vez que se ha produci¬ 
do un interbloqueo. Esperas demasiado cortas produ¬ 
cen el retroceso de la transacción incluso si no hay 
interbloqueo, provocando un gasto de recursos. La ina¬ 
nición es también posible con este esquema. Por tanto 
el esquema basado en límite de tiempo tiene una apli¬ 
cación limitada. 

16.6.3. Detección y recuperación 
de interbloqueos 

Si el sistema no utiliza algún protocolo que asegure la 
ausencia de interbloqueos, entonces se debe usar un 
esquema de detección y recuperación. Periódicamente 
se invoca a un algoritmo que examina el estado del sis¬ 
tema para determinar si hay un interbloqueo. Si lo hay, 
entonces el sistema debe intentar recuperarse del inter¬ 
bloqueo. Para ello, el sistema debe: 

• Mantener información sobre la asignación de los 
elementos de datos a las transacciones, así como 
de toda petición de elemento de datos pendiente. 

• Proporcionar un algoritmo que use esta informa¬ 
ción para determinar si el sistema ha entrado en un 
estado de interbloqueo. 

• Recuperarse del interbloqueo cuando el algoritmo 
de detección determine que existe un interbloqueo. 

En este apartado se van a desarrollar estos puntos. 

16.6.3.1. Detección de interbloqueos 

Los interbloqueos se pueden describir con precisión 
por medio de un grafo dirigido llamado grafo de espe¬ 
ra. Este grafo consiste en un par G = ( V., A), siendo V 
el conjunto de vértices y A el conjunto de arcos. El con¬ 
junto de vértices consiste en todas las transacciones 
del sistema. Cada elemento del conjunto E de arcos es 
un par ordenado T¡ —> Tj. Si T¡ —* Tj pertenece a A 
entonces hay un arco dirigido de la transacción T¡ a Tj, 
lo cual implica que la transacción T¡ está esperando a 
que la transacción Tj libere un elemento de datos que 
necesita. 
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Cuando la transacción T¡ solicita un elemento de 
datos que posee actualmente la transacción Tj, entonces 
se inserta el arco T¡ —> Tj en el grafo de espera. Este arco 
sólo se borra cuando la transacción Tj deja de poseer un 
elemento de datos que necesite la transacción Tj. 

Existe un interbloqueo en el sistema si y sólo si el 
grafo de espera contiene un ciclo. Se dice que toda tran¬ 
sacción involucrada en el ciclo está interbloqueada. Para 
detectar los interbloqueos el sistema debe mantener el 
grafo de espera y debe invocar periódicamente a un algo¬ 
ritmo que busque un ciclo en el grafo. 

Para ilustrar estos conceptos considérese el grafo de 
espera de la Figura 16.18, el cual describe la situación 
siguiente: 

• La transacción T 25 está esperando a las transac¬ 
ciones r 26 y T 21 . 

• La transacción T 21 está esperando a la transacción 

T 26 - 

• La transacción T 26 está esperando a la transacción 
^28- 

Puesto que el grafo no tiene ciclos, el sistema no está 
en un estado de interbloqueo. 

Supóngase ahora que la transacción Tj 8 solicita un 
elemento que posee T 21 . Se añade el arco 7’ 28 —* T 21 al 
grafo de espera, lo que resulta en el nuevo estado que 
se ilustra en la Figura 16.19. Ahora el grafo tiene el ciclo 

^26 ^28 T'n * T 2 6 

lo que implica que las transacciones T 26 , T 21 y T 28 están 
interbloqueadas. 

Por consiguiente surge la pregunta: ¿cuándo se debe 
invocar al algoritmo de detección? La respuesta depen¬ 
de de dos factores: 

1. ¿Cada cuánto tiempo tiene lugar un interbloqueo? 

2. ¿Cuántas transacciones se verán afectadas por el 
interbloqueo? 

Si los interbloqueos ocurren con frecuencia, entonces 
se debe invocar al algoritmo de detección con mayor fre¬ 
cuencia de la usual. Los elementos de datos asignados a 
las transacciones interbloqueadas no estarán disponibles 
para otras transacciones hasta que pueda romperse el 
interbloqueo. Adicionalmente puede también aumentar 



FIGURA 16.18. Grafo de espera sin ciclos. 



FIGURA 16.19. Grafo de espera con un ciclo. 

el número de ciclos en el grafo. En el caso peor se invo¬ 
ca al algoritmo de detección cada vez que una petición 
de asignación no se pueda conceder inmediatamente. 

16.6.3.2. Recuperación de interbloqueos 

Cuando un algoritmo de detección de interbloqueos 
determina que existe un interbloqueo, el sistema debe 
recuperarse del mismo. La solución más común es 
retroceder una o más transacciones para romper el inter¬ 
bloqueo. Se deben realizar tres acciones: 

1. Selección de una víctima. Dado un conjunto de 
transacciones interbloqueadas se debe determi¬ 
nar la transacción (o transacciones) que se van a 
retroceder para romper el interbloqueo. Se deben 
retroceder aquellas transacciones que incurran en 
un coste mínimo. Por desgracia, el término cos¬ 
te mínimo no es preciso. Hay muchos factores que 
determinan el coste de un retroceso, como 

a. Lo que la transacción ha calculado y lo que se 
calculará hasta completar su tarea designada. 

b. El número de elementos de datos que ha usa¬ 
do la transacción. 

c. La cantidad de elementos de datos que nece¬ 
sita la transacción para que se complete. 

d. El número de transacciones que se verán 
involucradas en el retroceso. 

2. Retroceso. Una vez que se ha decidido que se retro¬ 
cederá una transacción en particular, se debe deter¬ 
minar hasta dónde se retrocederá dicha transacción. 

La solución más simple consiste en un retroce¬ 
so total: se aborta la transacción y luego vuelve a 
comenzar. Sin embargo, es más efectivo retroceder 
la transacción sólo lo necesario para romper el inter¬ 
bloqueo. Dicho retroceso parcial requiere que el 
sistema mantenga información adicional sobre el 
estado de todas las transacciones que están en eje¬ 
cución. Concretamente, es necesario registrar la 
secuencia de solicitudes / concesiones de bloque¬ 
os y de actualizaciones realizadas por la transac¬ 
ción. El mecanismo de detección de interbloqueos 
debería decidir qué bloqueos necesita liberar la tran¬ 
sacción seleccionada para romper el interbloqueo. 
Hay que retroceder la transacción seleccionada has¬ 
ta el punto donde obtuvo el primero de esos blo¬ 
queos, deshaciendo todas las acciones que realizó 
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desde ese punto. El mecanismo de recuperación 
debe ser capaz de realizar tales retrocesos parcia¬ 
les. Además, las transacciones deben ser capaces 
de reanudar la ejecución después de un retroceso 
parcial. Véase el apartado de notas bibliográficas 
para obtener las referencias pertinentes. 

3. Inanición. En un sistema en el cual la selección 
de víctimas esté basada principalmente en fac¬ 


tores de coste, puede ocurrir que siempre se eli¬ 
ja a la misma transacción como víctima. El 
resultado es que esta transacción no completa 
nunca su tarea designada. Dicha situación se 
denomina inanición. Se debe asegurar que una 
transacción puede elegirse como víctima sólo 
un número finito (y pequeño) de veces. La solu¬ 
ción más común consiste en incluir en el factor 
de coste el número de retrocesos. 


16.7. OPERACIONES PARA INSERTAR Y BORRAR 


Hasta ahora se ha centrado la atención en las operacio¬ 
nes leer y escribir. Esta ligadura limita a las transaccio¬ 
nes a los elementos de datos que ya están en la base de 
datos. Algunas transacciones necesitan no sólo acceder 
a los elementos de datos existentes, sino también poder 
crear nuevos elementos de datos. Otras necesitan tener 
la posibilidad de borrar elementos de datos. Para exa¬ 
minar la forma en que tales transacciones afectan al con¬ 
trol de concurrencia se introducen las operaciones adi¬ 
cionales siguientes: 

• borrar(0 borra de la base de datos el elemento 
de datos Q. 

• insertar(0 inserta en la base de datos el nuevo 
elemento de datos Q y le asigna un valor inicial. 

Si la transacción T¡ intenta ejecutar una operación 
leer(<2) después de haberse borrado Q se produce un 
error lógico en T¡. Igualmente, si la transacción T¡ inten¬ 
ta ejecutar una operación leer(0 antes de que Q se haya 
insertado produce un error lógico en T¡. También es un 
error lógico intentar borrar un dato inexistente. 

16.7.1. Borrado 

Para comprender la manera en que puede afectar la pre¬ 
sencia de las instmcciones borrar al control de concu¬ 
rrencia, se debe decidir en qué casos una instrucción 
borrar está en conflicto con otra instrucción. Sean 7, e 
Ij instrucciones de T¡ y 7’ ; , respectivamente, que están 
consecutivas en la planificación S. Sea /, = borrar(0. 
Se consideran distintas instmcciones /■ 

• Ij = leer(0. 7, e /■ están en conflicto. Si /, está antes 
de /■, Tj tendrá un error lógico. Si / / está antes de 
I¡, Tj puede ejecutar con éxito su operación leer. 

• Ij = escribir(0. /, e /■ están en conflicto. Si /, está antes 
de Ij, Tj tendrá un error lógico. Si I¡ está antes de I¡, 
Tj puede ejecutar con éxito su operación escribir. 

• Ij = borrar(0. /, e I¡ están en conflicto. Si /, está 
antes de /■, 7) tendrá un error lógico. Si /, está antes 
de I¡, T¡ tendrá un error lógico. 


• I¡ = ¡nsertar(0. I¡ e / ( están en conflicto. Supónga¬ 
se que no existe el elemento de datos Q antes de la 
ejecución de 7, e /•. Entonces si 7, está antes de 1¡, 
hay un error lógico en T¡. Si I ¡ está antes de I¡, enton¬ 
ces no hay ningún error lógico. Igualmente si Q exis¬ 
tía antes de la ejecución de /, e 7, entonces hay un 
error lógico si / / está antes de I¡, pero no en otro caso. 

Se puede concluir lo siguiente: 

• En el protocolo de dos fases se necesita un blo¬ 
queo exclusivo en un elemento de datos antes de 
que se borre dicho elemento. 

• En el protocolo de ordenación por marcas tempo¬ 
rales se debe hacer una prueba similar que la que 
se hacía con escribir. Supóngase que la transacción 
T¡ ejecuta borrar(0. 

— Si MT(r ; ) < marea_temporaI-L( 0, entonces el 
valor de Q que va a borrar T¡ lo ha leído ya otra 
transacción Tj con MT(7j) > MT(r,). Por tanto 
se rechaza la operación borrar y T¡ se retroce¬ 
de. 

— Si MT(r,) < marca_temporal-E(0, entonces 
la transacción Tj con MT(7j) > MT(r,) ha escri¬ 
to 0 Por tanto se rechaza esta operación 
borrar y T¡ se retrocede. 

— En otro caso se ejecuta la operación borrar. 

16.7.2. Inserción 

Ya se ha visto que una operación ¡nsertar(0 está en 
conflicto con una operación borrar(0. De forma simi¬ 
lar ¡nsertar(0 está en conflicto con las operaciones 
leer(0 y escribir(0. No se pueden realizar operacio¬ 
nes leer o escribir sobre un elemento de datos hasta que 
este último exista. 

Puesto que insertar(0 asigna un valor al elemento 
de datos 0 se trata insertar de forma similar a escribir 
desde el punto de vista del control de concurrencia: 

• En el protocolo de bloqueo de dos fases, si T¡ rea¬ 
liza una operación insertar(Q), se da a T¡ un blo- 
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queo exclusivo sobre el elemento de datos Q 
recientemente creado. 

• En el protocolo de ordenación por marcas tempo¬ 
rales, si T¡ realiza una operación insertar((2), se 
fijan los valores marca_temporal-L(2) y mar- 
ca_temporal-E(0 a MT(r,). 

16.7.3. El fenómeno fantasma 

Considérese una transacción T 29 que ejecuta la siguien¬ 
te pregunta SQL a la base de datos bancaria: 

select sum(saldo) 
from cuenta 

where nombre-sucursal = ‘Pamplona’ 

La transacción T 29 necesita acceder a todas las tupias de 
la relación cuenta que pertenezcan a la sucursal Pam¬ 
plona. 

Sea T 30 una transacción que ejecuta la siguiente inser¬ 
ción SQL: 

inserí into cuenta 

valúes (‘Pamplona’, C-201, 900) 

Sea P una planificación que involucra a T 2g y T 30 . Se 
espera que haya un conflicto potencial debido a las razo¬ 
nes siguientes: 

• Si r 29 utiliza la tupia que ha insertado recientemente 
T 30 al calcular sum (saldo), entonces 7’ 29 lee el valor 
que ha escrito T 30 . Así, en una planificación secuen- 
cial equivalente a S, T 30 debe ir antes de T 29 . 

• Si T 29 no utiliza la tupia que ha insertado recien¬ 
temente T 3 o al calcular sum(saldo), entonces en 
una planificación secuencial equivalente a S, T 19 
debe ir antes de T 30 . 

El segundo caso de los dos es curioso. T 29 y T 30 no acce¬ 
den a ninguna tupia común, ¡y sin embargo están en 
conflicto! En efecto, T 29 y T 30 están en conflicto en una 
tupia fantasma. Si se realiza el control de concurrencia 
con granularidad de tupia, no se detecta dicho conflic¬ 
to. Este problema recibe el nombre de fenómeno fan¬ 
tasma. 

Para evitar el fenómeno fantasma se permite que T 29 
impida a otras transacciones crear nuevas tupias en la 
relación cuenta con nombre-sucursal - ‘Pamplona’. 

Para encontrar todas las tupias de cuenta con nom¬ 
bre-sucursal = ‘Pamplona’, T 29 debe buscar o bien en 
toda la relación cuenta, o al menos en un índice de la 
relación. Hasta ahora se ha asumido implícitamente que 
los únicos elementos de datos a los que accede una tran¬ 
sacción son tupias. Sin embargo T 29 es un ejemplo de 
transacción que lee información acerca de qué tupias 
pertenecen a una relación, y T 30 es un ejemplo de tran¬ 
sacción que actualiza dicha información. 


Claramente no es suficiente bloquear las tupias a 
las que se accede; se necesita también bloquear la 
información acerca de qué tupias pertenecen a la rela¬ 
ción. 

La solución más simple a este problema consiste en 
asociar un elemento de datos con la propia relación; el 
elemento de datos representa la información utilizada 
para encontrar las tupias en la relación. Las transaccio¬ 
nes como r 29 , que lean la información acerca de qué 
tupias pertenecen a la relación, tendrían que bloquear 
el elemento de datos correspondientes a la relación en 
modo compartido. Las transacciones como T 30 , que 
actualicen la información acerca de qué tupias pertene¬ 
cen a la relación, tendrían que bloquear el elemento de 
datos en modo exclusivo. De este modo T 29 y T 30 ten¬ 
drían un conflicto en un elemento de datos real, en lugar 
de tenerlo en uno fantasma. 

No se debe confundir el bloqueo de una relación 
completa, como en el bloqueo de granularidad múlti¬ 
ple, con el bloqueo del elemento de datos correspon¬ 
diente a la relación. Al bloquear el elemento de datos 
la transacción sólo evita que otras transacciones actua¬ 
licen la información acerca de qué tupias pertenecen a 
la relación. Sigue siendo necesario un bloqueo de 
tupias. Una transacción que acceda directamente a una 
tupia puede obtener un bloqueo sobre las tupias inclu¬ 
so si otra transacción posee un bloqueo exclusivo sobre 
el elemento de datos correspondiente a la propia rela¬ 
ción. 

El inconveniente principal de bloquear un elemento 
de datos correspondiente a la relación es el bajo grado 
de concurrencia —se impide que dos transacciones que 
inserten distintas tupias en la relación se ejecuten con¬ 
currentemente. 

Una solución mejor es la técnica de bloqueo de índi¬ 
ce. Toda transacción que inserte una tupia en una rela¬ 
ción debe insertar información en cada uno de los índi¬ 
ces que se mantengan en la relación. Se elimina el 
fenómeno fantasma al imponer un protocolo para los ín¬ 
dices. Para simplificar, sólo se van a considerar los 
índices del árbol B + . 

Como se vio en el Capítulo 12, todo valor de la clave 
de búsqueda se asocia a un nodo hoja índice. Una con¬ 
sulta usará normalmente uno o más índices para acce¬ 
der a la relación. Una inserción debe insertar una nueva 
tupia en todos los índices de la relación. En el ejemplo 
se asume que hay un índice para cuenta en nombre- 
sucursal. Entonces T 30 debe modificar la hoja que con¬ 
tiene la clave Pamplona. Si T 29 lee el mismo nodo hoja 
para localizar todas las tupias que pertenecen a la sucur¬ 
sal Pamplona, entonces T 29 y T 30 tienen un conflicto en 
dicho nodo hoja. 

El protocolo de bloqueo de índice toma las venta¬ 
jas de la disponibilidad de índices en una relación con¬ 
virtiendo las apariciones del fenómeno fantasma en con¬ 
flictos en los bloqueos sobre los nodos hoja índice. El 
protocolo opera de la siguiente manera: 
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• Toda relación debe tener al menos un índice. 

• Una transacción T¡ puede acceder a las tupias de 
una relación únicamente después de haberlas 
encontrado primero a través de uno o más índices 
de la relación. 

• Una transacción T¡ que realiza una búsqueda (o 
bien una búsqueda de rango o una búsqueda con¬ 
creta) debe bloquear en modo compartido todos 
los nodos hoja índice a los que accede. 

• Una transacción T¡ no puede insertar, borrar o actua¬ 
lizar una tupia t¡ en una relación r sin actualizar todos 
los índices de r. La transacción debe obtener blo¬ 
queos en modo exclusivo sobre todos los nodos hoja 
índice que están afectados por la inserción, el borra¬ 
do o la actualización. Para la inserción y el borrado, 


los nodos hoja afectados son aquellos que contienen 
(después de la inserción) o han contenido (antes de 
la modificación) el valor de la clave de búsqueda en 
la tupia. Para las actualizaciones, los nodos hoja afec¬ 
tados son los que (antes de la modificación) contie¬ 
nen el valor antiguo de la clave de búsqueda y los 
nodos que (después de la modificación) contienen 
el nuevo valor de la clave de búsqueda. 

• Hay que cumplir las reglas del protocolo de blo¬ 
queo de dos fases. 

Existen variantes de la técnica de bloqueo de índice 
para eliminar el fenómeno fantasma con otros protoco¬ 
los de control de concurrencia que se han presentado en 
este capítulo. 


16.8. NIVELES DÉBILES DE CONSISTENCIA 


La secuencialidad es un concepto útil porque permite a 
los programadores ignorar los problemas relacionados 
con la concurrencia cuando codifican las transacciones. 
Si todas las transacciones tienen la propiedad de mante¬ 
ner la consistencia de la base de datos si se ejecutan por 
separado, la secuencialidad asegura que las ejecuciones 
concurrentes mantienen la consistencia. Sin embargo, 
puede que los protocolos necesarios para asegurar la 
secuencialidad permitan muy poca concurrencia para algu¬ 
nas aplicaciones. En estos casos se utilizan los niveles 
más débiles de consistencia. El uso de niveles más débi¬ 
les de consistencia añade una nueva carga a los progra¬ 
madores para asegurar la corrección de las bases de datos. 

16.8.1. Consistencia de grado dos 

El objetivo de la consistencia de grado dos es evitar 
abortar en cascada sin asegurar necesariamente la 
secuencialidad. El protocolo de bloqueo para la consis¬ 
tencia de grado dos utiliza los mismos dos modos de 
bloqueo que se utilizan para el protocolo de bloqueo de 
dos fases: compartido (C) y exclusivo (X). Las transac¬ 
ciones deben mantener el modo de bloqueo adecuado 
cuando tengan acceso a un elemento de datos. 

A diferencia de la situación en los bloqueos de dos 
fases, los bloqueos-C pueden liberarse en cualquier 
momento y también se pueden establecer bloqueos en 
cualquier momento. Los bloqueos exclusivos no se pue¬ 
den liberar hasta que la transacción se comprometa o se 
aborte. La secuencialidad no queda asegurada por este 
protocolo. En realidad, una transacción puede leer dos 
veces el mismo elemento de datos y obtener resultados 
diferentes. En la Figura 16.20, T 3 lee el valor de Q antes 
y después de que T 4 escriba su valor. 

La posibilidad de que se produzca inconsistencia con 
la consistencia de grado dos hace que este enfoque no 
sea conveniente para muchas aplicaciones. 


16.8.2. Estabilidad del cursor 

La estabilidad del cursor es una forma de consisten¬ 
cia de grado dos diseñada para programas escritos en 
lenguajes de propósito general, los cuales iteran sobre 
las tupias de una relación utilizando cursores. En vez 
de bloquear toda la relación, la estabilidad del cursor 
asegura que 

• La tupia que está procesando la iteración esté blo¬ 
queada en modo compartido. 

• Todas las tupias modificadas estén bloqueadas en 
modo exclusivo hasta que se comprometa la tran¬ 
sacción. 

16.8.3. Niveles débiles de consistencia en SQL 

La norma SQL también permite que una transacción 
especifique si puede ser ejecutada de tal forma que se 
convierta en no secuenciable con respecto a otras tran¬ 
sacciones. Por ejemplo, una transacción puede operar 
en el nivel sin compromiso de lectura, lo que permi¬ 
te que la transacción lea registros incluso si éstos no se 
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FIGURA 16.20. Planificación no secuenciable con consisten¬ 
cia de grado dos. 
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han comprometido. SQL proporciona tales caracterís¬ 
ticas para transacciones largas cuyos resultados no nece¬ 
sitan ser precisos. Por ejemplo, una información apro¬ 
ximada suele ser suficiente para las estadísticas utilizadas 
en la optimización de consultas. Si estas transacciones 
se ejecutaran en modo secuencial, podrían interferir con 
otras transacciones, provocando que la ejecución de las 
otras se retrasara. 

Los niveles de consistencia especificados por SQL- 
92 son los siguientes: 

• Secuenciable es el predeterminado. 

• Lectura repetible sólo permite leer registros com¬ 
prometidos, y además requiere que, entre dos lec¬ 
turas de un registro realizadas por una transacción, 
no se permita que ninguna otra transacción actua¬ 
lice el registro. Sin embargo, la transacción puede 
no ser secuenciable con respecto a otras transac¬ 


ciones. Por ejemplo, cuando está buscando regis¬ 
tros que satisfagan algunas condiciones, una tran¬ 
sacción podría encontrar algunos de los registros 
que ha insertado una transacción comprometida, 
pero podría no encontrar otros. 

• Compromiso de lectura sólo permite leer registros 
comprometidos, pero ni siquiera requiere lecturas 
repetibles. Por ejemplo, entre dos lecturas de un 
registro realizadas por una transacción, los registros 
deben ser actualizados por otras transacciones com¬ 
prometidas. Esto es básicamente lo mismo que la 
consistencia de grado dos; la mayoría de los siste¬ 
mas que soportan este nivel de consistencia debería 
implementar en realidad estabilidad del cursor, que 
es un caso especial de consistencia de grado dos. 

• Sin compromiso de lectura permite incluso leer 
registros no comprometidos. Éste es el nivel de 
consistencia más bajo que permite SQL-92. 


16.9. CONCURRENCIA EN ESTRUCTURAS DE ÍNDICE** 


Es posible tratar el acceso a las estructuras de índice como 
el de otras estmcturas de base de datos y aplicar las téc¬ 
nicas de control de concurrencia que se han descrito ante¬ 
riormente. Sin embargo, puesto que se accede frecuen¬ 
temente a los índices, se pueden convertir en un punto 
con mucho bloqueo, lo que produce un bajo grado de 
concurrencia. Por suerte, no es necesario tratar a los índi¬ 
ces como a las demás estructuras de base de datos. Es 
perfectamente aceptable que una transacción busque en 
un índice dos veces y se encuentre con que la estructura 
del índice ha cambiado entre ambas búsquedas, mientras 
la búsqueda devuelva el conjunto correcto de tupias. De 
este modo se acepta tener un acceso no secuenciable a 
un índice mientras siga siendo correcto dicho índice. 

A continuación se mostrarán dos técnicas para tratar 
los accesos concurrentes a árboles B + . En las notas biblio¬ 
gráficas se hace referencia a otras técnicas para árboles 
B + , así como a técnicas para otras estructuras de índice. 

Las técnicas que se presentan para el control de con¬ 
currencia en los árboles B + se basan en el bloqueo, pero 
no se emplean ni el bloqueo de dos fases ni el protoco¬ 
lo de árbol. Los algoritmos de búsqueda, inserción y 
borrado son los mismos que se usan en el Capítulo 12 
con sólo algunas pequeñas modificaciones. 

La primera técnica se denomina protocolo del can¬ 
grejo: 

• Cuando se busca un valor clave, el protocolo del 
cangrejo bloquea primero el nodo raíz en modo 
compartido. Cuando se recorre el árbol hacia aba¬ 
jo, adquiere un bloqueo compartido sobre el 
siguiente nodo hijo. Después de adquirir el blo¬ 
queo sobre el nodo hijo, libera el bloqueo sobre el 


nodo padre. Repite este proceso hasta que alcan¬ 
za un nodo hoja. 

• Cuando se inserta o se borra un valor clave, el pro¬ 
tocolo del cangrejo realiza estas acciones: 

— Sigue el mismo protocolo que para la búsque¬ 
da hasta que alcanza el nodo hoja deseado. 
Hasta este punto, obtiene (y libera) tan sólo 
bloqueos compartidos. 

— Bloquea el nodo hoja en modo exclusivo e 
inserta o borra el valor clave. 

— Si necesita dividir un nodo o combinarlo con 
sus hermanos, o redistribuir los valores claves 
entre hermanos, el protocolo del cangrejo blo¬ 
quea al padre del nodo en modo exclusivo. 
Después de realizar estas acciones, libera los 
bloqueos sobre el nodo y los hermanos. 

Si el padre requiere división, combinación 
o redistribución de valores clave, el protocolo 
mantiene el bloqueo sobre el padre, y la divi¬ 
sión, la combinación o la redistribución se sigue 
propagando de la misma manera. En otro caso, 
libera el bloqueo sobre el padre. 

El protocolo obtiene su nombre de la forma en que 
los cangrejos avanzan moviéndose de lado, moviendo 
las patas de un lado, después las patas del otro, y así 
alternando sucesivamente. El avance de los bloqueos 
mientras el protocolo baja por el árbol o sube de nuevo 
(en el caso de divisiones, combinaciones o redistribu¬ 
ciones) actúa de forma similar a la del cangrejo. 

Una vez que una operación particular libera un blo¬ 
queo sobre un nodo, otras operaciones pueden acceder 
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a ese nodo. Existe una posibilidad de interbloqueos entre 
las operaciones de búsqueda que bajan por el árbol, y 
las divisiones, combinaciones y redistribuciones que se 
propagan hacia arriba por el árbol. El sistema puede 
manejar con facilidad tales interbloqueos reiniciando la 
operación de búsqueda desde la raíz, después de libe¬ 
rar los bloqueos mantenidos por la operación. 

La segunda técnica consigue aún más concurrencia, 
impidiendo incluso que se mantenga un bloqueo sobre 
un nodo mientras se está adquiriendo el bloqueo sobre 
otro nodo, utilizando una versión modificada de los árbo¬ 
les B + llamados árboles B enlazados; los árboles B 
enlazados requieren que todo nodo (incluyendo los 
nodos internos, no sólo las hojas) mantenga un punte¬ 
ro a su hermano derecho. Se necesita este puntero por¬ 
que una búsqueda que tenga lugar mientras se divide un 
nodo puede que tenga que buscar no sólo ese nodo sino 
también el hermano derecho de ese nodo (si existe algu¬ 
no). Esta técnica se va a ilustrar con un ejemplo des¬ 
pués de presentar los procedimientos modificados del 
protocolo de bloqueo con árboles B enlazados. 

• Búsqueda. Se debe bloquear en modo compartido 
cada nodo del árbol B + antes de que se acceda a él. 
Dicho bloqueo se libera antes de que se solicite 
algún otro bloqueo sobre algún nodo del árbol B + . 
Si tiene lugar una división de forma concurrente 
con una búsqueda, el valor de la clave de búsque¬ 
da deseado puede dejar de aparecer dentro del ran¬ 
go de valores que representa un nodo que se ha acce¬ 
dido en la búsqueda. En tal caso se representa el 
valor de la clave de búsqueda por medio de un nodo 
hermano, el cual coloca el sistema siguiendo el pun¬ 
tero al hermano derecho. Sin embargo, el sistema 
bloquea los nodos hoja siguiendo el protocolo de 
bloqueo de dos fases, como se describe en el Apar¬ 
tado 16.7.3, para evitar el fenómeno fantasma. 

• Inserción y borrado. El sistema sigue las reglas 
de la búsqueda para localizar el nodo sobre el cual 
se va a realizar la inserción o el borrado. Se modi¬ 
fica el bloqueo en modo compartido sobre ese nodo 
a modo exclusivo y se realiza la inserción o el 
borrado. Se bloquean los nodos hoja afectados por 
la inserción o el borrado siguiendo el protocolo de 


bloqueo de dos fases, como se describe en el Apar¬ 
tado 16.7.3, para evitar el fenómeno fantasma. 

• División. Si se divide un nodo se crea uno nuevo 
siguiendo el algoritmo del Apartado 12.3 y se con¬ 
vierte en el hermano derecho del nodo original. Se 
fijan los punteros al hermano derecho del nodo ori¬ 
ginal (ya que es un nodo interno; los nodos hoja 
se bloquean en dos fases) y del nuevo nodo. Segui¬ 
damente se libera el bloqueo en modo exclusivo 
sobre el nodo original y se solicita un bloqueo sobre 
el padre para que se pueda insertar un nuevo nodo. 
(No hay necesidad de bloquear o desbloquear el 
nuevo nodo.) 

• Fusión. Si un nodo tiene muy pocos valores de 
clave de búsqueda después de un borrado, se debe 
bloquear en modo exclusivo el nodo con el que se 
debe fusionar. Una vez que se fusionen estos nodos 
se solicita un bloqueo en modo exclusivo sobre el 
padre para que se pueda eliminar el nodo borrado. 
En ese momento se libera el bloqueo sobre el nodo 
fusionado. Se libera el bloqueo sobre el nodo padre 
a no ser que también se tenga que fusionar. 

Es importante observar que una inserción o un borrado 
pueden bloquear un nodo, desbloquearlo y posterior¬ 
mente volverlo a bloquear. Además una búsqueda que 
se ejecute concurrentemente con operaciones de divi¬ 
sión o de combinación puede observar que la clave de 
búsqueda deseada se ha trasladado al nodo hermano 
derecho debido a la división o a la combinación. 

Como ejemplo considérese el árbol B + de la Figura 
16.21. Supóngase que hay dos operaciones concurren¬ 
tes sobre dicho árbol B + : 

1. Insertar «Cádiz» 

2. Buscar «Daimiel» 

Considérese que la operación inserción comienza en 
primer lugar. Realiza una búsqueda de «Cádiz» y 
encuentra que el nodo en el cual se debe insertar «Cádiz» 
está vacío. Por tanto convierte el bloqueo compartido 
sobre el nodo en un bloqueo exclusivo y crea un nuevo 
nodo. El nodo original contiene ahora los valores de cla¬ 
ve de búsqueda «Barcelona» y «Cádiz». El nuevo nodo 
contiene el valor de clave de búsqueda «Daimiel». 




Barcelona 



Barcelona 




nodo hoja 






C-212 

Barcelona 

750 

C-101 

Daimiel 

500 

C-110 

Daimiel 

600 



archivo cuenta 


FIGURA 16.21. Nodo hoja para el índice del árbol B + de cuenta (n = 3). 
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FIGURA 16.22. Inserción de «Cádiz» en el árbol B + de la Figura 16.21. 


Supóngase ahora que se produce un cambio de con¬ 
texto que le pasa el control a la operación búsqueda. 
Dicha operación búsqueda accede a la raíz y sigue el 
puntero al hijo izquierdo de la raíz. Accede entonces a 
ese nodo y obtiene el puntero al hijo izquierdo. El hijo 
izquierdo contenía originalmente los valores de clave 
de búsqueda «Barcelona» y «Daimiel». Puesto que la 
operación inserción está bloqueando actualmente en 
modo exclusivo dicho nodo, la operación búsqueda debe 
esperar. Nótese que, en este punto, ¡la operación bús¬ 
queda no posee ningún bloqueo! 

Ahora la operación inserción desbloquea el nodo hoja 
y vuelve a bloquear a su padre en esta ocasión en modo 
exclusivo. Se completa la inserción, lo que deja al árbol 
B+ como se muestra en la Figura 16.22. Continúa la 
operación de búsqueda. Sin embargo, tiene un puntero 
a un nodo hoja incorrecto. Sigue, por tanto, el puntero 
al hermano derecho para encontrar el nodo siguiente. 
Si este nodo es también incorrecto, se sigue también el 
puntero al hermano derecho. Se puede demostrar que, 
si una búsqueda tiene un puntero a un nodo incorrecto 
entonces, al seguir los punteros al hermano derecho, la 
búsqueda llega finalmente al nodo correcto. 

Las operaciones de búsqueda y de inserción no pue¬ 
den llevar a un interbloqueo. La combinación de nodos 
durante el borrado puede provocar inconsistencias, dado 
que una búsqueda puede tener que leer un puntero a un 
nodo borrado desde su padre, antes de que el nodo padre 
sea actualizado y, entonces, puede intentar acceder al 
nodo borrado. La búsqueda se tendría que reiniciar 
entonces desde la raíz. Dejar los nodos sin combinar 
evita tales inconsistencias. Esta solución genera nodos 


que contienen muy pocos valores clave de búsqueda y 
que violan algunas propiedades de los árboles B+. Sin 
embargo, en la mayoría de las bases de datos las inser¬ 
ciones son más frecuentes que los borrados, por lo que 
es probable que los nodos que tienen muy pocos valo¬ 
res claves de búsqueda ganen valores adicionales de for¬ 
ma relativamente rápida. 

En lugar de bloquear nodos hoja índice en dos fases, 
algunos esquemas de control de concurrencia de índices 
utilizan bloqueo de valores clave sobre valores claves 
individuales, permitiendo que se inserten o se borren 
otros valores clave de la misma hoja. Por lo tanto, el blo¬ 
queo de valores clave proporciona una concurrencia 
mejorada. Sin embargo, utilizar el bloqueo de valores 
clave ingenuamente podría permitir que se produjera el 
fenómeno fantasma; para prevenir el fenómeno fantas¬ 
ma se utiliza la técnica bloqueo de la siguiente clave. En 
esta técnica, cada búsqueda por índice debe bloquear no 
sólo las claves encontradas dentro del rango (o la única 
clave, en caso de una búsqueda concreta), sino también 
el siguiente valor clave, esto es, el valor clave que es jus¬ 
to mayor que el último valor clave que estaba dentro del 
rango. Además, cada inserción no sólo debe bloquear el 
valor que se inserta, sino también el siguiente valor cla¬ 
ve. Así, si una transacción intenta insertar un valor que 
estaba dentro del rango de la búsqueda por índice de otra 
transacción, las dos transacciones entrarán en conflicto 
en el valor clave que sigue al valor clave insertado. De 
forma similar, los borrados también deben bloquear el 
siguiente valor clave al valor que se ha borrado, para ase¬ 
gurar que se detecten los conflictos con las subsiguien¬ 
tes búsquedas de rango de otras consultas. 


16.10. RESUMEN 


• Cuando se ejecutan concurrentemente varias tran¬ 
sacciones en la base de datos, puede dejar de conser¬ 
varse la consistencia de los datos. Es necesario que el 
sistema controle la interacción entre las transaccio¬ 
nes concurrentes, y dicho control se lleva a cabo 
mediante uno de los muchos mecanismos llamados 
esquemas de control de concurrencia. 

• Se pueden usar varios esquemas de control de con¬ 
currencia para asegurar la secuencialidad. Todos estos 


esquemas o bien retrasan una operación o bien abor¬ 
tan la transacción que ha realizado la operación. Los 
más comunes son los protocolos de bloqueo, los 
esquemas de ordenación por marcas temporales, las 
técnicas de validación y los esquemas multiversión. 

• Un protocolo de bloqueo es un conjunto de reglas, las 
cuales indican el momento en el que una transacción 
puede bloquear o desbloquear un elemento de datos 
de la base de datos. 
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El protocolo de bloqueo de dos fases permite que una 
transacción bloquee un nuevo elemento de datos sólo 
si todavía no ha desbloqueado ningún otro elemento 
de datos. Este protocolo asegura la secuencialidad 
pero no la ausencia de interbloqueos. En ausencia de 
información acerca de la forma en que se accede a los 
elementos de datos, el protocolo de bloqueo de dos 
fases es necesario y suficiente para asegurar la secuen¬ 
cialidad. 

El protocolo de bloqueo estricto de dos fases permi¬ 
te liberar bloqueos exclusivos sólo al final de la tran¬ 
sacción, para asegurar la recuperabilidad y la ausen¬ 
cia de cascadas en las planificaciones resultantes. El 
protocolo de bloqueo riguroso de dos fases libera 
todos los bloqueos sólo al final de la transacción. 

El esquema de ordenación por marcas temporales ase¬ 
gura la secuencialidad seleccionando previamente un 
orden entre todo par de transacciones. Se asocia una 
única marca temporal fija a cada transacción del sis¬ 
tema. Las marcas temporales de las transacciones 
determinan el orden de secuencialidad. De este modo, 
si la marca temporal de la transacción T¡ es más peque¬ 
ña que la de la transacción 7j, entonces el esquema 
asegura que la planificación que ha producido es equi¬ 
valente a una planificación secuencial en la cual la 
transacción T¡ aparece antes de la transacción T¡. Lo 
asegura retrocediendo una transacción siempre que 
se viole dicho orden. 

Un esquema de validación es un método de control de 
concurrencia adecuado en aquellos casos en los que la 
mayoría de las transacciones son de sólo lectura, y por 
tanto la tasa de conflictos entre dichas transacciones 
es baja. Se asocia una única marca temporal fija a cada 
transacción del sistema. Se determina el orden de 
secuencialidad por medio de la marca temporal. Nun¬ 
ca se retrasa una transacción en dicho esquema. Debe 
pasar, sin embargo, una comprobación de validación 
para poder completarse. Si no pasa la comprobación 
de validación se retrocede a su estado inicial. 

Hay circunstancias bajo las cuales puede ser conve¬ 
niente agrupar varios elementos de datos y tratarlos 
como un conjunto de elementos de datos por motivos 
del trabajo, lo que da lugar a varios niveles de gra- 
nularidad. Se permiten elementos de datos de varios 
tamaños y se define una jerarquía de elementos de 
datos en la cual los elementos más pequeños están 
anidados dentro de otros más grandes. Dicha jerar¬ 
quía se puede representar de forma gráfica como un 
árbol. El orden de obtención de los bloqueos es des¬ 
de la raíz hasta la hojas; se liberan desde las hojas has¬ 
ta la raíz. Este protocolo asegura la secuencialidad 
pero no la ausencia de interbloqueos. 

Un esquema de control de concurrencia multiversión 
se basa en crear una nueva versión de un elemento de 
datos cada vez que una transacción va a escribir dicho 
elemento. Cuando se realiza una operación de lectu¬ 


ra, el sistema elige una de las versiones para que se 
lea. El esquema de control de concurrencia asegura 
que la versión que se va a leer se elige de forma que 
asegure la secuencialidad usando las marcas tempo¬ 
rales. Una operación de lectura tiene éxito siempre. 

— En la ordenación por marcas temporales multi¬ 
versión, una operación de escritura puede provo¬ 
car el retroceso de una transacción. 

— En el bloqueo de dos fases multiversión las ope¬ 
raciones de escritura pueden provocar una espera 
con bloqueo o posiblemente un interbloqueo. 

• Algunos de los protocolos de bloqueo no evitan los 
interbloqueos. Una forma de prevenir los interblo¬ 
queos es utilizar una ordenación de los elementos de 
datos, y solicitar los bloqueos en una secuencia con¬ 
sistente con la ordenación. 

• Otra forma de prevenir los interbloqueos es utilizar 
expropiación y retroceso de transacciones. Para con¬ 
trolar la expropiación se asigna una única marca tem¬ 
poral a cada transacción. El sistema utiliza estas mar¬ 
cas temporales para decidir si una transacción debe 
esperar o retroceder. Si una transacción se retrocede 
conserva su marca temporal anterior cuando vuelve 
a comenzar. El esquema herir-esperar es un esquema 
de expropiación. 

• Si no se pueden prevenir los interbloqueos, el siste¬ 
ma debe ocuparse de ellos utilizando el esquema de 
detección y recuperación de interbloqueos. Para hacer 
esto, el sistema constmye un grafo de espera. Un sis¬ 
tema está en estado de interbloqueo si y sólo si con¬ 
tiene un ciclo en el grafo de espera. Cuando el algo¬ 
ritmo de detección de interbloqueos determina que 
existe un interbloqueo, el sistema debe recuperarse 
del interbloqueo. Esto se lleva a cabo retrocediendo 
una o más transacciones para romper el interbloqueo. 

• Se puede realizar una operación borrar sólo si la tran¬ 
sacción que borra la tupia tiene un bloqueo en modo 
exclusivo sobre dicha tupia. Ala transacción que inser¬ 
ta una nueva tupia se le concede un bloqueo en modo 
exclusivo sobre dicha tupia. 

• Las inserciones pueden provocar el fenómeno fan¬ 
tasma, en el cual hay un conflicto entre una inserción 
y una pregunta incluso si las dos transacciones no 
acceden a tupias comunes. Tales conflictos no se pue¬ 
den detectar si el bloqueo se ha hecho sólo sobre tupias 
a las que han accedido transacciones. Es necesario 
bloquear los datos utilizados para encontrar las tupias 
en la relación. La técnica del bloqueo de índice resuel¬ 
ve este problema al exigir bloqueos sobre ciertos cajo¬ 
nes de índices. Estos bloqueos aseguran que todas las 
transacciones conflictivas están en conflicto por un 
elemento de datos real en lugar de por uno fantasma. 

• Los niveles débiles de consistencia se utilizan en algu¬ 
nas aplicaciones cuando la consistencia de los resul¬ 
tados de la consulta no es crítica, y utilizar secuen- 
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cialidad podría dar lugar a consultas que afectaran 
desfavorablemente al procesamiento de transaccio¬ 
nes. La consistencia de grado dos es uno de los nive¬ 
les de consistencia débiles; la estabilidad de cursor 
es un caso especial de consistencia de grado dos y se 
utiliza bastante. SQL: 1999 permite a las consultas 
especificar el nivel de consistencia requerido. 


• Se pueden desarrollar técnicas de control de concu¬ 
rrencia para estmcturas especiales. A menudo se apli¬ 
can técnicas especiales en los árboles B + para permi¬ 
tir una mayor concurrencia. Estas técnicas permiten 
accesos no secuenciables al árbol B + , pero aseguran 
que la estructura del árbol B + es correcta y que los 
accesos a la base de datos son secuenciables. 


TÉRMINOS DE REPASO 


• Bloqueo 

— Compatibilidad 
— Concesión 
— Espera 
— Solicitud 

• Bloqueo de dos fases multiversión 

— Transacciones de actualización 
— Transacciones de sólo lectura 

• Concurrencia en índices 

— Árboles B enlazados 
— Bloqueo de la siguiente clave 
— Cangrejo 

— Protocolo de bloqueo con árboles B enlazados 

• Control de concurrencia 

• Control de concurrencia multiversión 

• Conversión de bloqueo 

— Bajar 
— Subir 

• Detección de interbloqueos 

— Grafo de espera 

• Fenómeno fantasma 

— Protocolo de bloqueo de índice 
— Sin compromiso de lectura 

• Granularidad múltiple 

— Bloqueos explícitos 
— Bloqueos implícitos 
— Bloqueos intencionales 

• Inanición 

• Interbloqueo 

• Marca temporal 

— Contador lógico 

— marca_temporal-E(C?) 

— marca_temporal-L(Q) 

— Reloj del sistema 

• Modos de bloqueo intencionales 

— Intencional-compartido (IC) 

— Intencional-exclusivo (IX) 

— Intencional-exclusivo y compartido (IXC) 

• Niveles débiles de consistencia 

— Compromiso de lectura 
— Consistencia de grado dos 


— Estabilidad del cursor 
— Lectura repetible 

• Operaciones para insertar y borrar 

• Ordenación por marcas temporales multiversión 

• Planificación legal 

• Prevención de interbloqueos 

— Bloqueos ordenados 
— Esquema esperar-morir 
— Esquema herir-esperar 
— Esquemas basados en tiempo límite 
— Expropiación de bloqueos 

• Protocolo de bloqueo 

• Protocolo de bloqueo de dos fases 

— Bloqueo estricto de dos fases 
— Bloqueo riguroso de dos fases 
— Fase de crecimiento 
— Fase de decrecimiento 

• Protocolo de bloqueo de granularidad múltiple 

• Protocolo de ordenación por marcas temporales 

— Regla de escritura de Thomas 

• Protocolos basados en grafos 

— Dependencia de compromiso 
— Protocolo de árbol 

• Protocolos basados en validación 

— Comprobación de validación 
— Fase de escritura 
— Fase de lectura 
— Fase de validación 

• Protocolos basados en marcas temporales 

• Punto de bloqueo 

• Tipos de bloqueo 

— Bloqueo en modo compartido (C) 

— Bloqueo en modo exclusivo (X) 

• Recuperación de interbloqueos 

— Retroceso parcial 
— Retroceso total 

• Tratamiento de interbloqueos 

— Detección 
— Prevención 
— Recuperación 

• Versiones 
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EJERCICIOS 


16.1. Demuéstrese que el protocolo de bloqueo de dos fases 
asegura la secuencialidad en cuanto a conflictos y que 
se pueden secuenciar las transacciones a través de sus 
puntos de bloqueo. 

16.2. Considérense las dos transacciones siguientes: 

T 31 : leer(A); 
leer(B); 
si A = 0 

entonces B := B + 1; 

escribir(B) 

T 32 : leer(B); 
leer(A); 
si B = 0 

entonces A := A + 1; 

escribir(A). 

Añádanse a las transacciones T 3I y T 32 las instruccio¬ 
nes de bloqueo y desbloqueo para que sigan el proto¬ 
colo de dos fases. ¿Puede producir la ejecución de 
estas transacciones un interbloqueo? 

16.3. ¿Qué beneficio proporciona el bloqueo estricto de dos 
fases? ¿Qué inconvenientes tiene? 

16.4. ¿Qué beneficio proporciona el bloqueo riguroso de 
dos fases? Compárese con otras formas de bloqueo 
de dos fases. 

16.5. Muchas implementaciones de sistemas de bases de 
datos utilizan el bloqueo estricto de dos fases. Indí- 
quense tres razones que expliquen la popular idad de 
este protocolo. 

16.6. Considérese una base de datos organizada como un 
árbol con raíz. Supóngase que se inserta un nodo 
ficticio entre cada par de nodos. Demuéstrese que, 
si se sigue el protocolo de árbol con este nuevo 
árbol, se obtiene mayor concurrencia que con el 
árbol original. 

16.7. Demuéstrese con un ejemplo que hay planificaciones 
que son posibles con el protocolo de árbol que no lo 
son con otros protocolos de bloqueo de dos fases y 
viceversa. 

16.8. Considérese la siguiente extensión del protocolo de 
bloqueo de árbol que permite bloqueos compartidos 
y exclusivos: 

• Una transacción puede ser de sólo lectura, en cuyo 
caso sólo puede solicitar bloqueos compartidos, 
o bien puede ser de actualización, en cuyo caso 
sólo puede solicitar bloqueos exclusivos. 

• Cada transacción debe seguir las reglas del pro¬ 
tocolo de árbol. Las transacciones de sólo lectu¬ 
ra deben bloquear primero cualquier elemento 
de datos, mientras que las transacciones de actua¬ 
lización deben bloquear primero la raíz. 

Demuéstrese que este protocolo asegura la secuen¬ 
cialidad y la ausencia de interbloqueos. 


16.9. Considérese el siguiente protocolo de bloqueo basa¬ 
do en grafo, el cual sólo permite bloqueos exclusivos 
y que funciona con grafos de datos con forma de gra¬ 
fo dirigido acíclico con raíz. 

• Una transacción puede bloquear en primer lugar 
cualquier nodo. 

• Para bloquear cualquier otro nodo, la transac¬ 
ción debe poseer un bloqueo sobre la mayoría 
de los padres de dicho nodo. 

Demuéstrese que este protocolo asegura la secuen¬ 
cialidad y la ausencia de interbloqueos. 

16.10. Considérese el siguiente protocolo de bloqueo basa¬ 
do en grafos que sólo permite bloqueos exclusivos y 
que funciona con grafos de datos con forma de grafo 
dirigido acíclico con raíz. 

• Una transacción puede bloquear en primer lugar 
cualquier nodo. 

• Para bloquear cualquier otro nodo, la transac¬ 
ción debe haber visitado a todos los padres de 
dicho nodo y debe poseer un bloqueo sobre uno 
de los padres del vértice. 

Demuéstrese que este protocolo asegura la secuen¬ 
cialidad y la ausencia de interbloqueos. 

16.11. Considérese una variante del protocolo de árbol lla¬ 
mada protocolo de bosque. La base de datos está orga¬ 
nizada como un bosque de árboles con raíz. Cada tran¬ 
sacción T¡ debe seguir las reglas siguientes: 

• El primer bloqueo en un árbol puede hacerse 
sobre cualquier elemento de datos. 

• Se pueden solicitar el segundo y posteriores blo¬ 
queos sólo si el padre del nodo solicitado está 
bloqueado actualmente. 

• Se pueden desbloquear los elementos de datos 
en cualquier momento. 

• T j no puede volver a bloquear un elemento de 
datos después de haberlo desbloqueado. 

Demuéstrese que el protocolo de bosque no asegura 
la secuencialidad. 

16.12. El bloqueo no se hace explícitamente en lenguajes de 
programación persistentes. En vez de esto se deben 
bloquear los objetos (o sus páginas correspondientes) 
cuando se accede a dichos objetos. Muchos de los sis¬ 
temas operativos más modernos permiten al usuario 
definir protecciones de acceso (sin acceso, lectura, 
escritura) para las páginas, y aquellos accesos a memo¬ 
ria que violen las protecciones de acceso dan como 
resultado una violación de protección (véase la orden 
mprotect de Unix, por ejemplo). Descríbase la for¬ 
ma en que se puede usar el mecanismo de protección 
de acceso para bloqueos a nivel de página en lengua¬ 
jes de programación persistentes. ( Sugerencia : La téc¬ 
nica es algo parecida a la que se usaba para el resca¬ 
te hardware del Apartado 11.9.4.) 
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X 

1 

c 

cierto 

falso 

falso 

X 

falso 

falso 

falso 

1 

falso 

falso 

cierto 


FIGURA 16.23. Matriz de compatibilidad de bloqueos. 

16.13. Considérese una base de datos que tiene la operación 
atómica incrementar además de las operaciones leer 
y escribir. Sea V el valor del elemento de datos X. La 
operación 

incrementar(X) en C 

asigna el valor V+C a X en un paso atómico. El valor 
de X no está disponible hasta que no se ejecute pos¬ 
teriormente una operación leer(A'). En la Figura 16.17 
se muestra una matriz de compatibilidad de bloqueos 
para tres tipos de bloqueo: modo compartido, exclu¬ 
sivo y de incremento. 

a. Demuéstrese que, si todas las transacciones blo¬ 
quean el dato al que acceden en el modo corres¬ 
pondiente, entonces el bloqueo de dos fases ase¬ 
gura la secuencialidad. 

b. Demuéstrese que la inclusión del bloqueo en modo 
incrementar permite una mayor concurrencia. 
(Sugerencia: Considérense las transacciones de 
transferencia de fondos del ejemplo bancario.) 

16.14. En la ordenación por marcas temporales, marca_tem- 
poral-E(0 indica la mayor marca temporal de todas 
las transacciones que hayan ejecutado escr¡bir(0 con 
éxito. Supóngase que en lugar de ello, marca_tein- 
porai-E(0 se define como la marca temporal de la 
transacción más reciente que haya ejecutado escri¬ 
bir^) con éxito. ¿Hay alguna diferencia al cambiar 
esta definición? Razónese la respuesta. 

16.15. Cuando se retrocede una transacción en el protocolo 
de ordenación por marcas temporales se le asigna una 
nueva marca temporal. ¿Por qué no puede conservar 
simplemente su antigua marca temporal? 

16.16. En el protocolo de granularidad múltiple, ¿qué dife¬ 
rencia hay entre bloqueo implícito y explícito? 

16.17. Aunque el modo IXC es útil para el bloqueo de gra¬ 
nularidad múltiple, no se usa un modo exclusivo e 
intencional-compartido (ICX). ¿Por qué no es útil? 

16.18. La utilización de un bloqueo de granularidad múlti¬ 
ple puede necesitar más o menos bloqueos que en un 
sistema equivalente con una granularidad simple de 
bloqueo. Proporciónense ejemplos de ambas situa¬ 
ciones y compárese el aumento relativo de la concu¬ 
rrencia que se permite. 

16.19. Considérese el esquema de control de concurrencia 
basado en la validación del Apartado 16.3. Demués¬ 
trese que si se elige Validación) 7?) en lugar de Ini- 
cio(T¡) como marca temporal de la transacción T¡, se 
puede esperar una mejor respuesta en tiempo debido 
a que la tasa de conflictos entre las transacciones es 
realmente baja. 

16.20. Demuéstrese que hay planificaciones que son posi¬ 
bles con el protocolo de bloqueo de dos fases que no 


lo son con el protocolo de marcas temporales y vice¬ 
versa. 

16.21. Para cada uno de los protocolos siguientes, descrí¬ 
banse los aspectos de aplicación práctica que sugie¬ 
ran utilizar el protocolo y aspectos que sugieran no 
usarlo: 

• Bloqueo de dos fases 

• Bloqueo de dos fases con granularidad múltiple 

• Protocolo de árbol 

• Ordenación por marcas temporales 

• Validación 

• Ordenación por marcas temporales multiversión 

• Bloqueo de dos fases multiversión 

16.22. En una versión modificada del protocolo de marcas 
temporales se necesita comprobar un bit de compro¬ 
miso para saber si una petición de lectura debe espe¬ 
rar o no. Expliqúese cómo puede evitar el bit de com¬ 
promiso que aborten en cascada. ¿Por qué no se 
necesita hacer esta comprobación con las peticiones 
de escritura? 

16.23. Expliqúese por qué la siguiente técnica de ejecución 
de transacciones puede proporcionar mayor rendi¬ 
miento que la utilización del bloqueo estricto de dos 
fases: primero se ejecuta la transacción sin adquirir 
ningún bloqueo y sin realizar ninguna escritura en la 
base de datos como en las técnicas basadas en vali¬ 
dación, pero a diferencia de las técnicas de validación 
no se realiza otra validación o escritura en la base de 
datos. En cambio, se vuelve a ejecutar la transacción 
utilizando bloqueo estricto de dos fases. (Sugerencia: 
Considérense esperas para la E/S de disco.) 

16.24. ¿Bajo qué condiciones es menos costoso evitar los 
interbloqueos que permitirlos y luego detectarlos? 

16.25. Si se evitan los interbloqueos, ¿sigue siendo posible 
que haya inanición? Razónese la respuesta. 

16.26. Considérese el protocolo de ordenación por marcas 
temporales, y dos transacciones, una que escribe dos 
elementos de datos p y q, y otra que lee los mismos 
dos elementos de datos. Obténgase una planificación 
por medio de la cual la comprobación por marcas tem¬ 
porales para una operación escribir falle y provoque 
el reinicio de la primera transacción, provocando a su 
vez una cancelación en cascada de la otra transacción. 
Muéstrese cómo esto podría acabar en inanición de 
las dos transacciones. (Tal situación, donde dos o más 
procesos realizan acciones, pero no se puede com¬ 
pletar la tarea porque se interacciona con otros pro¬ 
cesos, se denomina interbloqueo.) 

16.27. Expliqúese el fenómeno fantasma. ¿Por qué produce 
este fenómeno una ejecución concurrente incorrecta 
a pesar de utilizar el protocolo de bloqueo de dos 
fases? 

16.28. Diséñese un protocolo basado en marcas temporales 
que evite el fenómeno fantasma. 

16.29. Expliqúese la razón por la cual se utiliza la consisten¬ 
cia de grado dos. ¿Qué desventajas tiene esta técnica? 

16.30. Supóngase que se utiliza el protocolo de árbol del Apar¬ 
tado 16.1.5 para administrar el acceso concurrente a 
un árbol B + . Puesto que puede haber una división en 
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una inserción que afecte a la raíz, se deduce que una 
operación inserción no puede liberar ningún bloqueo 
hasta que se complete la operación entera. ¿Bajo qué 
circunstancias es posible liberar antes un bloqueo? 


16.31. Dense ejemplos de planificaciones para mostrar que 
si cualquier búsqueda, inserción o borrado no bloquea 
el siguiente valor clave, el fenómeno fantasma podría 
ser indetectable. 
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SISTEMA DE RECUPERACIÓN 


U na computadora, al igual que cualquier otro dispositivo eléctrico o mecánico, está suje¬ 
ta a fallos. Éstos se producen por diferentes motivos como: fallos de disco, cortes de 
corriente, errores en el software, un incendio en la habitación de la computadora o inclu¬ 
so sabotaje. En cada uno de estos casos puede perderse información. Por tanto, el sistema de 
bases de datos debe realizar con anticipación acciones que garanticen que las propiedades de 
atomicidad y durabilidad de las transacciones, presentadas en el Capítulo 15, se preservan a 
pesar de tales fallos. Una parte integral de un sistema de bases de datos es un esquema de recu¬ 
peración, el cual es responsable de la restauración de la base de datos al estado consistente pre¬ 
vio al fallo. El esquema de recuperación también debe proporcionar alta disponibilidad; esto 
es, debe minimizar el tiempo durante el que la base de datos no se puede usar después de un 
fallo. 


17.1. CLASIFICACIÓN DE LOS FALLOS 


En un sistema pueden producirse varios tipos de fallos, 
cada uno de los cuales requiere un tratamiento diferen¬ 
te. El tipo de fallo más fácil de tratar es el que no con¬ 
duce a una pérdida de información en el sistema. Los 
fallos más difíciles de tratar son aquellos que provocan 
una pérdida de información. En este capítulo conside¬ 
raremos sólo los siguientes tipos de fallos: 

• Fallo en la transacción. Hay dos tipos de errores 
que pueden hacer que una transacción falle: 

— Error lógico. La transacción no puede conti¬ 
nuar con su ejecución normal a causa de algu¬ 
na condición interna, como una entrada inco¬ 
rrecta, datos no encontrados, desbordamiento 
o exceso del límite de recursos. 

— Error del sistema. El sistema se encuentra en 
un estado no deseado (por ejemplo, de inter¬ 
bloqueo) como consecuencia del cual una tran¬ 
sacción no puede continuar con su ejecución 
normal. La transacción, sin embargo, se pue¬ 
de volver a ejecutar más tarde. 

• Caída del sistema. Un mal funcionamiento del 
hardware o un error en el software de la base de 
datos o del sistema operativo causa la pérdida del 
contenido de la memoria volátil y aborta el proce¬ 
samiento de una transacción. El contenido de la 
memoria no volátil permanece intacto y no se 
corrompe. 

La suposición de que los errores de hardware o 
software fuercen una parada del sistema, pero no 
corrompan el contenido de la memoria no volátil, 
se conoce como supuesto de fallo-parada. Los 


sistemas bien diseñados tienen numerosas com¬ 
probaciones internas, al nivel de hardware y de 
software, que abortan el sistema cuando existe un 
error. De aquí que el supuesto de fallo-parada sea 
razonable. 

• Fallo de disco. Un bloque del disco pierde su con¬ 
tenido como resultado de bien una colisión de la 
cabeza lectora, bien un fallo durante una operación 
de transferencia de datos. Las copias de los datos 
que se encuentran en otros discos o en archivos de 
seguridad en medios de almacenamiento secun¬ 
darios, como cintas, se utilizan para recuperarse 
del fallo. 

Para determinar cómo el sistema debe recuperarse de 
los fallos, es necesario identificar los modos de fallo 
de los dispositivos de almacenamiento. A continuación 
se verá cómo afectan estos modos de fallo a los conte¬ 
nidos de la base de datos. Entonces se pueden proponer 
algoritmos para garantizar la consistencia de la base de 
datos y la atomicidad de las transacciones a pesar de los 
fallos. Estos algoritmos se conocen como algoritmos de 
recuperación, aunque constan de dos partes: 

1. Acciones llevadas a cabo durante el procesa¬ 
miento normal de transacciones para asegurar que 
existe información suficiente para permitir la recu¬ 
peración frente a fallos. 

2. Acciones llevadas a cabo después de ocurrir un 
fallo para restablecer el contenido de la base de 
datos a un estado que asegure la consistencia de 
la base de datos, la atomicidad de la transacción 
y la durabilidad. 
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17.2. ESTRUCTURA DEL ALMACENAMIENTO 


Como vimos en el Capítulo 10, los diferentes elemen¬ 
tos que componen una base de datos pueden ser alma¬ 
cenados y accedidos con diferentes medios de almace¬ 
namiento. Para entender cómo se pueden garantizar las 
propiedades de atomicidad y durabilidad de una tran¬ 
sacción, se deben comprender mejor estos medios de 
almacenamiento y sus métodos de acceso. 

17.2.1. Tipos de almacenamiento 

En el Capítulo 11 se vio que los medios de almacena¬ 
miento se pueden distinguir según su velocidad relati¬ 
va, capacidad, y resistencia a fallos, y se pueden clasi¬ 
ficar como almacenamiento volátil o no volátil. Se 
repasarán estos términos y se introducirá otra clase de 
almacenamiento, denominada almacenamiento estable. 

• Almacenamiento volátil. La información que resi¬ 
de en almacenamiento volátil no suele sobrevivir 
a las caídas del sistema. La memoria principal y la 
memoria caché son ejemplos de este almacena¬ 
miento. El acceso al almacenamiento volátil es 
muy rápido, tanto por la propia velocidad de acce¬ 
so a la memoria, como porque es posible acceder 
directamente a cualquier elemento de datos. 

• Almacenamiento no volátil. La información que 
reside en almacenamiento no volátil sobrevive a 
las caídas del sistema. Los discos y las cintas mag¬ 
néticas son ejemplos de este almacenamiento. Los 
discos se utilizan para almacenamiento en cone¬ 
xión, mientras que las cintas se usan para almace¬ 
namiento permanente. Ambos, sin embargo, pue¬ 
den fallar (por ejemplo, colisión de la cabeza 
lectora), lo que puede conducir a una pérdida de 
información. En el estado actual de la tecnología, 
el almacenamiento no volátil es más lento en varios 
órdenes de magnitud que el almacenamiento volá¬ 
til. Esta diferencia de velocidad es consecuencia 
de que los dispositivos de disco y de cinta sean 
electromecánicos, mientras que el almacenamien¬ 
to volátil se basa por completo en circuitos inte¬ 
grados, como el almacenamiento volátil. En los 
sistemas de bases de datos los discos se utilizan 
fundamentalmente para el almacenamiento no 
volátil. Otros medios de almacenamiento no volá¬ 
til sólo se usan normalmente para copias de segu¬ 
ridad de los datos. El almacenamiento flash (véa¬ 
se el Apartado 11.1), aunque no volátil, tiene 
capacidad insuficiente para la mayoría de los sis¬ 
temas de bases de datos. 

• Almacenamiento estable. La información que 
reside en almacenamiento estable nunca se pierde 
(bueno, nunca diga nunca jamás, porque teórica¬ 
mente el nunca no puede garantizarse; por ejem¬ 


plo, es posible, aunque extremadamente improba¬ 
ble, que un agujero negro se trague a la Tierra y 
¡destruya para siempre todos los datos!). A pesar 
de que el almacenamiento estable es teóricamente 
imposible de conseguir, puede obtenerse una bue¬ 
na aproximación usando técnicas que hagan que la 
pérdida de información sea una posibilidad muy 
remota. La implementación del almacenamiento 
estable se discute en el Apartado 17.2.2. 

Las diferencias entre los distintos tipos de almacena¬ 
miento son, con frecuencia, menos claras en la prácti¬ 
ca que en la presentación anterior. Ciertos sistemas están 
provistos de una fuente de alimentación de seguridad, 
por lo que determinada memoria principal puede sobre¬ 
vivir a las caídas del sistema y a cortes de corriente. 
Otras formas alternativas de almacenamiento no volá¬ 
til, como los medios ópticos, ofrecen un grado de con¬ 
fianza incluso más alto que el de los discos. 

17.2.2. Implementación del almacenamiento 
estable 

Para implementar almacenamiento estable se debe repli¬ 
car la información necesaria en varios medios de alma¬ 
cenamiento no volátil (normalmente discos) con modos 
de fallo independientes, y actualizar esa información de 
manera controlada para asegurar que un fallo durante 
una transferencia de datos no dañará la información 
necesaria. 

Recuérdese (en el Capítulo 10) que los sistemas 
RAID (disposición redundante de discos independien¬ 
tes) garantizan que el fallo de un solo disco (incluso 
durante una transferencia de datos) no conduce a la pér¬ 
dida de los datos. La variante más sencilla y rápida de 
un RAID es el disco con imagen, que guarda dos copias 
de cada bloque en distintos discos. Otras formas de 
RAID ofrecen menores costes a expensas de un rendi¬ 
miento inferior. 

Los sistemas RAID, sin embargo, no pueden prote¬ 
ger contra las pérdidas de datos debidas a desastres tales 
como un incendio o una inundación. Muchos sistemas 
de almacenamiento guardan copias de seguridad de las 
cintas en otro lugar como protección frente a tales desas¬ 
tres. No obstante, como las cintas no pueden ser trasla¬ 
dadas a otro lugar continuamente, los cambios que se 
hayan realizado después del último traslado de las cin¬ 
tas se perderán en caso de un desastre tal. Los sistemas 
más seguros guardan una copia de cada bloque de alma¬ 
cenamiento estable en un lugar remoto, escribiéndola a 
través de una red de computadoras, además de almace¬ 
nar el bloque en un sistema de discos locales. Como los 
bloques se envían al sistema remoto al mismo tiempo 
y de la misma forma que se guardan en almacenamien¬ 
to local, una vez que una operación de este tipo se com- 
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pleta los bloques copiados no pueden perderse, incluso 
en el caso de que ocurriese un desastre como un incen¬ 
dio o una inundación. En el Apartado 17.10 se estudian 
estos sistemas de copia de seguridad remota. 

En el resto de este apartado se discute la manera de 
proteger a los medios de almacenamiento de los erro¬ 
res durante una transferencia de datos. Una transferen¬ 
cia de bloques entre la memoria y el disco puede aca¬ 
bar de diferentes formas: 

• Éxito. La información transferida llega a su des¬ 
tino con seguridad. 

• Fallo parcial. Ocurre un fallo en medio de la trans¬ 
ferencia y el bloque de destino contiene informa¬ 
ción incorrecta. 

• Fallo total. El fallo ocurre suficientemente pron¬ 
to durante la transferencia para que el bloque de 
destino permanezca intacto. 

Es necesario que, si se produce un fallo durante una 
transferencia de datos, el sistema lo detecte e invoque 
a un procedimiento de recuperación para restaurar el 
bloque a un estado estable. Para hacer esto, el sistema 
debe mantener dos bloques físicos por cada bloque lógi¬ 
co de la base de datos; en el caso de los discos con ima¬ 
gen, ambos bloques están en el mismo lugar; en el caso 
de copia de seguridad remota, uno de los bloques es 
local mientras que el otro está en un lugar remoto. Una 
operación de salida se ejecuta de la siguiente manera: 

1. Se escribe la información en el primer bloque físi¬ 
co. 

2. Cuando la primera escritura se completa con éxi¬ 
to, se escribe la misma información en el segun¬ 
do bloque físico. 

3. La salida está completada sólo después de que la 
segunda escritura finalice con éxito. 

Durante la recuperación se examina cada par de blo¬ 
ques físicos. Si ambos coinciden y no existe ningún error 
detectable, entonces no son necesarias más acciones. Si 
un bloque contiene un error detectable, se reemplaza su 
contenido por el del segundo bloque. Este procedimiento 
de recuperación garantiza que la escritura en almace¬ 
namiento estable o bien se completa con éxito (esto es, 
se actualizan todas las copias) o bien no produce nin¬ 
gún cambio. 

El requisito de comparar cada par correspondiente 
de bloques durante la recuperación es bastante costoso. 
Puede reducirse considerablemente ese coste si se regis¬ 
tran las escrituras de bloques que están en progreso uti¬ 
lizando una pequeña cantidad de RAM no volátil. En la 
recuperación solamente es necesario comparar aquellos 
bloques para los que la escritura estuviera en progreso. 

Los protocolos para escribir un bloque en un lugar 
remoto son similares a los utilizados para escribir blo¬ 
ques en un sistema de disco con imagen, que fueron exa¬ 


minados en el Capítulo 11 y, en particular, en el Ejerci¬ 
cio 11.4. 

Este procedimiento puede extenderse fácilmente para 
permitir el uso de un número arbitrariamente alto de 
copias de cada bloque de almacenamiento estable. Aun¬ 
que un elevado número de copias reduce la probabili¬ 
dad de fallo incluso por debajo de la conseguida con 
dos copias, habitualmente es razonable la simulación 
de almacenamiento estable con sólo dos copias. 

17.2.3. Acceso a los datos 

Como se vio en el Capítulo 11, el sistema de bases de 
datos reside permanentemente en almacenamiento no 
volátil (normalmente discos) y se divide en unidades de 
almacenamiento de longitud fija denominadas bloques. 
Los bloques son las unidades de datos que se transfie¬ 
ren desde y hacia el disco y pueden contener varios ele¬ 
mentos de datos. Supondremos que ningún elemento de 
datos mide dos o más bloques. Esta suposición es rea¬ 
lista para la mayoría de las aplicaciones de procesa¬ 
miento de datos tales como el ejemplo bancario. 

Las transacciones llevan información del disco hacia 
la memoria principal y luego devuelven la información 
al disco. Las operaciones de entrada y salida se reali¬ 
zan en unidades de bloque. Nos referiremos a los blo¬ 
ques que residen en el disco como bloques físicos, y a 
los que residen temporalmente en la memoria principal 
como bloques de memoria intermedia. El área de 
memoria en donde los bloques residen temporalmente 
se denomina memoria intermedia de disco. 

Las transferencias de un bloque entre disco y memo¬ 
ria principal se comienzan a través de las dos opera¬ 
ciones siguientes: 

1. entrada(/i) transfiere el bloque físico B a la memo¬ 
ria principal 

2. salida(R) transfiere el bloque de memoria inter¬ 
media B al disco y reemplaza allí al correspon¬ 
diente bloque físico. 

Este esquema se ilustra en la Figura 17.1. 



Disco 


Memoria principal 

FIGURA 17.1. Operaciones de almacenamiento de bloques. 
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Cada transacción T¡ posee un área de trabajo priva¬ 
da en la cual se guardan copias de todos los elementos 
de datos accedidos y actualizados por T¡. Esta área de 
trabajo se crea cuando se comienza una transacción y 
se elimina cuando la transacción o bien se comprome¬ 
te o bien aborta. Cada elemento de datos X almacena¬ 
do en el área de trabajo de la transacción T¡ se denota¬ 
rá como x¡. La transacción T¡ interactúa con el sistema 
de bases de datos por medio de transferencias de datos 
desde su área de trabajo hacia la memoria intermedia 
del sistema y viceversa. Nosotros realizaremos transfe¬ 
rencias de datos utilizando las dos operaciones siguien¬ 
tes: 

1. leer(A) asigna el valor del elemento de datos X a 
la variable local x¡. Esta operación se ejecuta como 
sigue: 

a. Si el bloque B x en el que reside X no está en la 
memoria principal, entonces se emite entra¬ 
da^). 

b. Asignar a x¡ el valor de X en el bloque de memo¬ 
ria intermedia. 

2. escribir(X) asigna el valor de la variable local x¡ al 
elemento de datos X en el bloque de memoria inter¬ 
media. Esta operación se ejecuta como sigue: 

a. Si el bloque B x en el que reside X no está en la 
memoria principal, entonces se lanza entra¬ 
da^). 


b. Asignar el valor de x¡ a A en la memoria inter¬ 
media B x . 

Nótese que ambas operaciones pueden requerir la trans¬ 
ferencia de un bloque desde disco a la memoria princi¬ 
pal. En cambio, ninguna de ellas requiere específica¬ 
mente la transferencia de un bloque desde la memoria 
principal al disco. 

Un bloque de memoria intermedia B se escribe final¬ 
mente en el disco bien porque el gestor de la memoria 
intermedia necesita espacio en memoria para otros pro¬ 
pósitos, o bien porque el sistema de base de datos desea 
reflejar en el disco los cambios sufridos por B. Diremos 
que el sistema de bases de datos fuerza la salida de la 
memoria intermedia B si ejecuta la orden salida(5). 

Cuando una transacción necesita acceder a un ele¬ 
mento de datos X por primera vez, debe ejecutar leer(A). 
Todas las actualizaciones de X se llevan a cabo sobre x¡. 
Después de que la transacción acceda a X por última 
vez, se debe ejecutar escribir(X) para reflejar en la pro¬ 
pia base de datos los cambios sufridos por X. 

La operación salida(fí x ) sobre el bloque de memoria 
intermedia B x en el que reside X no tiene por qué tener 
efecto inmediatamente después de ejecutar escribirfA), 
ya que el bloque B x puede contener otros elementos de 
datos que estén siendo accedidos todavía. Así, la salida 
real tiene lugar más tarde. Nótese que, si el sistema se 
bloquea después de ejecutar la operación escribí r(A'), 
pero antes de ejecutar salida(5 x ), el nuevo valor de X 
nunca se escribe en el disco y, por tanto, se pierde. 


17.3. RECUPERACIÓN Y ATOMICIDAD 


Considérese de nuevo el sistema bancario simplificado 
y una transacción T¡ que transfiere 50 € desde la cuen¬ 
ta A a la cuenta B, siendo los saldos iniciales de A y de 
B de 1.000 € y 2.000 € respectivamente. Supóngase 
que el sistema cae durante la ejecución de T¡ después de 
haberse ejecutado salida(5 A ), pero antes de la ejecución 
de salida(5 B ), donde B A y B b denotan los bloques de 
memoria intermedia en los que residen A y B. Al per¬ 
derse el contenido de la memoria no se sabe la suerte 
de la transacción; así, podríamos invocar uno de los dos 
procedimientos posibles de recuperación. 

• Volver a ejecutar T¡. Este procedimiento hará 
que el saldo de A se quede en 900 € en vez de en 
950 €. De este modo el sistema entra en un esta¬ 
do inconsistente. 

• No volver a ejecutar T¡. El estado actual del sis¬ 
tema otorga los valores de 950 € y 2.000 € para 
Ay B respectivamente. Por tanto, el sistema entra 
en un estado inconsistente. 

En cualquier caso se deja a la base de datos en un esta¬ 
do inconsistente y, por lo tanto, este esquema simple de 


recuperación de datos no funciona. El motivo de este mal 
funcionamiento es que se ha modificado la base de datos 
sin tener la seguridad de que la transacción se compro¬ 
meta realmente. El objetivo es realizar todos los cambios 
inducidos por T¡ o no llevar a cabo ninguno. Sin embar¬ 
go, si T¡ realiza varias modificaciones en la base de datos, 
pueden necesitarse varias operaciones de salida y puede 
ocurrir un fallo después de haberse concluido alguna de 
estas modificaciones, pero antes de haber terminado todas. 

Para conseguir el objetivo de la atomicidad se debe 
efectuar primero la operación de salida de la informa¬ 
ción que describe las modificaciones en el almacena¬ 
miento estable sin modificar todavía la base de datos. 
Como se verá, este procedimiento permitirá realizar la 
salida de todas las modificaciones realizadas por una 
transacción comprometida aunque se produzcan fallos. 
Hay dos formas de ejecutar tales salidas; se estudian en 
los Apartados 17.4 y 17.5. En estos dos apartados supon¬ 
dremos que las transacciones se ejecutan secuencial- 
mente, esto es, solamente una transacción está activa en 
cada momento. Se describirá la forma de manejar la eje¬ 
cución concurrente de transacciones más adelante, en 
el Apartado 17.6. 
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17.4. RECUPERACIÓN BASADA EN EL REGISTRO HISTÓRICO 


La estructura más ampliamente utilizada para guardar 
las modificaciones de una base de datos es el registro 
histórico. El registro histórico es una secuencia de regis¬ 
tros que mantiene un registro de todas las actividades 
de actualización de la base de datos. Existen varios tipos 
de registros del registro histórico. Un registro de actua¬ 
lización del registro histórico describe una única escri¬ 
tura en la base de datos y tiene los siguientes campos: 

• El identiflcador de la transacción es un identifi- 
cador único de la transacción que realiza la ope¬ 
ración escribir. 

• El identiflcador del elemento de datos es un iden- 
tificador único del elemento de datos que se escri¬ 
be. Normalmente suele coincidir con la ubicación 
del elemento de datos en el disco. 

• El valor anterior es el valor que tenía el elemen¬ 
to de datos antes de la escritura. 

• El valor nuevo es el valor que tendrá el elemento 
de datos después de la escritura. 

Existen otros registros del registro histórico especiales 
para registrar sucesos significativos durante el procesa¬ 
miento de una transacción, tales como el comienzo de 
una transacción y el éxito o aborto de la misma. Deno¬ 
taremos como sigue los diferentes tipos de registros del 
registro histórico: 

• <T¡ iniciadax La transacción T¡ ha comenzado. 

• <T¡, Xj, V lt V 2 >- La transacción T¡ ha realizado una 
escritura sobre el elemento de datos Xj. X } tenía el 
valor V l antes de la escritura y tendrá el valor V 2 
después de la escritura. 

• <T¡ comprometidax La transacción T¡ se ha com¬ 
prometido. 

• <T¡ abortadax La transacción T¡ ha sido aborta¬ 
da. 

Cuando una transacción realiza una escritura es funda¬ 
mental que se cree el registro del registro histórico 
correspondiente a esa escritura antes de modificar la 
base de datos. Una vez que el registro del registro his¬ 
tórico existe, se puede realizar la salida de la modifica¬ 
ción a la base de datos si se desea. Además, es posible 
deshacer una modificación que ya haya salido a la base 
de datos. Se deshará utilizando el campo valor-anterior 
de los registros del registro histórico. 

Para que los registros del registro histórico sean úti¬ 
les para recuperarse frente a errores del disco o del sis¬ 
tema, el registro histórico debe residir en almacena¬ 
miento estable. Por ahora supóngase que cada registro 
del registro histórico se escribe, tan pronto como se crea, 
al final del registro histórico en almacenamiento esta¬ 


ble. En el Apartado 17.7 se verán las condiciones nece¬ 
sarias para poder relajar este requisito de forma segura 
de modo que se reduzca la sobrecarga impuesta por el 
registro histórico. En los Apartados 17.4.1 y 17.4.2 se 
presentarán dos técnicas de utilización del registro his¬ 
tórico para garantizar la atomicidad frente a fallos. 
Obsérvese que en el registro histórico se tiene constan¬ 
cia de todas las actividades de la base de datos. Como 
consecuencia, el tamaño de los datos almacenados en 
el registro histórico puede llegar a ser extremadamente 
grande. En el Apartado 17.4.3 se mostrará bajo qué con¬ 
diciones se puede borrar información del registro his¬ 
tórico de manera segura. 

17.4.1. Modificación diferida de la base 
de datos 

La técnica de la modificación diferida garantiza la ato¬ 
micidad de las transacciones mediante el almacena¬ 
miento de todas las modificaciones de la base de datos 
en el registro histórico, pero retardando la ejecución de 
todas las operaciones escribir de una transacción hasta 
que la transacción se compromete parcialmente. Recuér¬ 
dese que se dice que una transacción se compromete 
parcialmente una vez que se ejecuta la acción final de 
la transacción. En la versión de la técnica de modifica¬ 
ción diferida que se describe en este apartado se supo¬ 
ne que las transacciones se ejecutan secuencialmente. 

Cuando una transacción se compromete parcial¬ 
mente, la información del registro histórico asociada a 
esa transacción se utiliza para la ejecución de las escri¬ 
turas diferidas. Si el sistema cae antes de que la tran¬ 
sacción complete su ejecución o si la transacción abor¬ 
ta, la información del registro histórico simplemente se 
ignora. 

La ejecución de una transacción T¡ opera de esta 
manera: antes de que T¡ comience su ejecución se escri¬ 
be en el registro histórico un registro <T¡ iniciadax Una 
operación escribirlo realizada por T¡ se traduce en la 
escritura de un nuevo registro en el registro histórico. 
Finalmente, cuando T¡ se ha comprometido parcial¬ 
mente, se escribe en el registro histórico un registro 
<T¡ comprometidax 

Cuando T¡ se compromete parcialmente, los registros 
asociados a ella en el registro histórico se utilizan para 
la ejecución de las escrituras diferidas. Como puede ocu¬ 
rrir un fallo mientras se lleva a cabo esta actualización, 
hay que asegurarse de que, antes del comienzo de estas 
actualizaciones, todos los registros del registro históri¬ 
co se guardan en almacenamiento estable. Una vez que 
se ha hecho esto, la actualización real tiene lugar y la 
transacción pasa al estado comprometido. 

Obsérvese que la técnica de modificación diferida 
sólo requiere el nuevo valor de los elementos de datos. 
Así, se puede simplificar la estructura general de los 
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registros de actualización del registro histórico que se 
vieron en el apartado anterior omitiendo el campo para 
el valor anterior. 

Para ilustrar esto reconsidérese el sistema bancario 
simplificado. Sea T 0 una transacción que transfiere 50 € 
desde la cuenta A a la cuenta #. Esta transacción se defi¬ 
ne de la manera siguiente: 

T 0 : leer(A) 

A :=A- 50 

escribir(A) 

leer(#) 

B :=# + 50 
escribir(5) 

Sea T\ una transacción que retira 100 € de la cuenta C. 
Esta transacción se define como 

7j : leer(C) 

C :=C - 100 
escribir(C) 

Supongamos que estas transacciones se ejecutan secuen- 
cialmente, primero T 0 y después 7), y que los saldos de 
las cuentas A, B y C antes de producirse la ejecución 
eran 1.000, 2.000 y 700 € respectivamente. El frag¬ 
mento del registro histórico que contiene la informa¬ 
ción relevante sobre estas dos transacciones se muestra 
en la Figura 17.2. 

Las salidas reales que se producen en el sistema de 
bases de datos y en el registro histórico como conse¬ 
cuencia de la ejecución de T 0 y 7j pueden seguir dis¬ 
tintas ordenaciones. Una ordenación posible se presen¬ 
ta en la Figura 17.3. Nótese que el valor de A se cambia 
en la base de datos sólo después de que el registro <T 0 , 
A , 950> se haya introducido en el registro histórico. 

Mediante la utilización del registro histórico, el sis¬ 
tema puede manejar cualquier fallo que conduzca a la 
pérdida de información en el almacenamiento volátil. 
El esquema de recuperación usa el siguiente procedi¬ 
miento de recuperación: 

• rehacefiY,) fija el valor de todos los elementos de 
datos actualizados por la transacción T¡ a los valo¬ 
res nuevos. 

El conjunto de elementos de datos actualizados por T¡ 
y sus respectivos nuevos valores se encuentran en el 
registro histórico. 

<T 0 iniciada> 

<T 0 , A, 950> 

<T 0 , B, 450> 

<T 0 comprometida> 

<T¡ ¡niciada> 

<U,c, noo> 

<7j comprometida> 

FIGURA 17.2. Fragmento del registro histórico de la base 
de datos correspondiente aí 0 y 7j. 


Registro histórico Base de datos 

<T 0 iniciada> 

<T 0 , A, 950> 

<r 0 , B, 2050> 

<T 0 comprometida> 

A = 950 

B = 2050 

<T\ iniciada> 

<T U C, 600> 

<7j comprometida> 

C = 600 

FIGURA 17.3. Estado del registro histórico y de la base de 
datos correspondiente a T 0 y 7j. 

La operación rehacer debe ser idempotente, esto es, 
el resultado de ejecutarla varias veces debe ser equiva¬ 
lente al resultado de ejecutarla una sola vez. Esta carac¬ 
terística es fundamental para garantizar un correcto com¬ 
portamiento incluso si el fallo se produce durante el 
proceso de recuperación. 

Después de ocurrir un fallo, el subsistema de recu¬ 
peración consulta el registro histórico para determinar 
las transacciones que deben rehacerse. Una transacción 
T¡ debe rehacerse si y sólo si el registro histórico con¬ 
tiene los registros <T¡ iniciada> y <T¡ comprometidax 
Así, si el sistema cae después de que la transacción com¬ 
plete su ejecución, la información en el registro histó¬ 
rico se utiliza para restituir el sistema a un estado con¬ 
sistente anterior. 

Para ilustrar esto volvamos a considerar el ejemplo 
bancario con la ejecución ordenada de las transacciones 
T 0 y 7j, primero 7 0 y después 7j. En la Figura 17.2 se 
muestra el registro histórico que resulta de la ejecución 
completa de T 0 yT x . Supóngase que el sistema cae antes 
de completarse las transacciones para poder ver el modo 
en que la técnica de recuperación lleva a la base de datos 
a un estado consistente. Supóngase que la caída ocurre 
justo después de haber escrito en almacenamiento esta¬ 
ble el registro del registro histórico para el paso 

escribid#) 

de la transacción 7 0 . El contenido del registro histórico 
en el momento de la caída puede verse en la Figura 
17.4a. Cuando el sistema vuelve a funcionar no es nece¬ 
sario llevar a cabo ninguna acción rehacer, ya que no 
aparece ningún registro de compromiso en el registro 
histórico. Los saldos de las cuentas Ay# siguen sien¬ 
do de 1.000 y 2.000 €. respectivamente. Pueden borrar¬ 
se del registro histórico los registros de la transacción 
incompleta T 0 . 

Supóngase ahora que la caída sucede justo después 
de haber escrito en almacenamiento estable el registro 
del registro histórico para el paso 

escribir(C) 

de la transacción T v En este caso, el contenido del regis¬ 
tro histórico en el momento de la caída puede verse en la 
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<T 0 iniciada> <T 0 ¡niciada> 

<r„,A,950> <J 0 ,A,950> 

<T 0 , B, 2050> <J 0 , B , 2050> 

<T 0 comprometida> 
<T¡ iniciada> 

<7\, C, 600> 

(a) (b) 


<T 0 iniciada> 

<T 0 , A, 950> 

<T 0 , B, 2050> 

<T 0 comprometida> 
<T 1 iniciada> 

<T U C, 600> 

<T 0 comprometida> 

(c) 


FIGURA 17.4. El mismo registro histórico que el de la Figura 17.3 en tres momentos distintos. 


Figura 17.4b. Cuando el sistema vuelve a funcionar se 
realiza la operación rehacer(r o ), ya que el registro 

<T 0 comprometida> 

aparece en el registro histórico en el disco. Después de 
la ejecución de esta operación, los saldos de las cuen¬ 
tas A y B son de 950 y 2.050 € respectivamente. El sal¬ 
do de la cuenta C se mantiene en 700 €. Igual que antes, 
pueden borrarse del registro histórico los registros de la 
transacción incompleta 7j. 

Por último, supóngase que la caída ocurre justo des¬ 
pués de haber escrito en almacenamiento estable el regis¬ 
tro del registro histórico 

<T 1 comprometida> 

El contenido del registro histórico en el momento de la 
caída se muestra en la Figura 17.4c. Cuando el sistema 
vuelve a funcionar, hay dos registros comprometida en 
el registro: uno para T 0 y otro para 7j. Así pues, deben 
realizarse las operaciones rehacer(r o ) y rehacer(r i ). 
Después de la ejecución de estas operaciones, los sal¬ 
dos de las cuentas A, B y C son de 950, 2.050 y 600 € 
respectivamente. 

Considérese finalmente un caso en el que tiene 
lugar una segunda caída del sistema durante la recu¬ 
peración de la primera. Deben hacerse algunos cam¬ 
bios en la base de datos como consecuencia de la eje¬ 
cución de las operaciones rehacer, pero no se han 
realizado todos los cambios. Cuando el sistema vuel¬ 
ve a funcionar después de la segunda caída, la recu¬ 
peración procede exactamente igual que en los ejem¬ 
plos anteriores. Para cada 

<T¡ comprometida> 

que se encuentre en el registro histórico, se lanza la ope¬ 
ración rehacepT,). En otras palabras, las acciones de 
recuperación se vuelven a reanudar desde el principio. 
Como rehacer escribe los valores en la base de datos 
independientemente de los datos que haya actualmen¬ 
te en la base de datos, el resultado de un segundo inten¬ 
to acabado con éxito en la ejecución de rehacer es el 
mismo que si rehacer hubiera acabado con éxito la pri¬ 
mera vez. 


17.4.2. Modificación inmediata de la base 
de datos 

La técnica de modificación inmediata permite reali¬ 
zar la salida de las modificaciones de la base de datos a 
la propia base de datos mientras que la transacción está 
todavía en estado activo. Las modificaciones de datos 
escritas por transacciones activas se denominan modi¬ 
ficaciones no comprometidas. En caso de una caída o 
de un fallo en la transacción, el sistema debe utilizar el 
campo para el valor anterior de los registros del regis¬ 
tro histórico descritos en el Apartado 17.4 para restau¬ 
rar los elementos de datos modificados a los valores que 
tuvieran antes de comenzar la transacción. Esta restau¬ 
ración se lleva a cabo mediante la operación deshacer 
descrita a continuación. 

Antes de comenzar la ejecución de una transacción 
T¡, se escribe en el registro histórico el registro <7j ini¬ 
ciadas Durante su ejecución, cualquier operación escri¬ 
bí r(A) realizada por T¡, es precedida por la escritura en 
el registro histórico de un registro actualizado apropia¬ 
do. Cuando T¡ se compromete parcialmente se escribe 
en el registro histórico el registro <T¡ comprometidas 

Como la información del registro histórico se utiliza 
para reconstruir el estado de la base de datos, la actua¬ 
lización real de la base de datos no puede permitirse antes 
de que el registro del registro histórico correspondiente 
se haya escrito en almacenamiento estable. Por lo tanto, 
es necesario que antes de la ejecución de una operación 
de salida(5), se escriban en almacenamiento estable los 
registros del registro histórico correspondientes a tí. Esto 
volverá a tratarse en el Apartado 17.7. 

Para ilustrarlo considérese de nuevo el sistema ban- 
cario simplificado con la ejecución ordenada de las tran¬ 
sacciones T 0 y r i7 primero T 0 y después 7’,. Las líneas 
del registro histórico que contienen la información rele¬ 
vante concerniente a estas dos transacciones se mues¬ 
tran en la Figura 17.5. 

En la Figura 17.6 se describe una posible ordenación 
de las salidas reales que se producen en el sistema de 
bases de datos y en el registro histórico como conse¬ 
cuencia de la ejecución de T 0 yT l . Nótese que esta orde¬ 
nación no podría obtenerse con la técnica de modifica¬ 
ción diferida que se vio en el Apartado 17.4.1. 

Mediante la utilización del registro histórico, el sis¬ 
tema puede manejar cualquier fallo que no genere una 
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<T 0 ¡niciada> 

<T 0 ,A, 1000, 950> 

<T 0 , B, 2000, 2050> 

<T 0 comprometida> 

<T 1 iniciada> 

<7), C, 700, 600> 

<T 1 comprometida> 

FIGURA 17.5. Fragmento del registro histórico del sistema 
correspondiente a T„ y T v 

Registro histórico Base de datos 

<T 0 iniciada> 

<T 0 ,A, 1000, 950> 

<T 0 , B, 2000, 2050> 

A = 950 
B = 2050 

<T 0 comprometida> 

<T¡ iniciada> 

<7,, C, 700, 600> 

C = 600 

<T l comprometida> 

FIGURA 17.6. Estado del registro histórico y de la base de 
datos correspondiente aí 0 y 7j. 

pérdida de información en el almacenamiento no volá¬ 
til. El esquema de recuperación usa dos procedimien¬ 
tos de recuperación: 

• deshacer(r ; ) restaura el valor de todos los ele¬ 
mentos de datos actualizados por la transacción T¡ 
a los valores anteriores. 

• rehaced'/’ ) fija el valor de todos los elementos de 
datos actualizados por la transacción T¡ a los nue¬ 
vos valores. 

El conjunto de elementos de datos actualizados por T¡ 
y sus respectivos anteriores y nuevos valores se encuen¬ 
tran en el registro histórico. 

Las operaciones deshacer y rehacer deben ser idem- 
potentes para garantizar un comportamiento correcto 
incluso en el caso de que el fallo se produzca durante 
el proceso de recuperación. 

Después de haberse producido un fallo, el esquema 
de recuperación consulta el registro histórico para deter¬ 


minar las transacciones que deben rehacerse y las que 
deben deshacerse. 

• Una transacción T¡ debe deshacerse si el registro 
histórico contiene el registro <T¡ iniciada>, pero no 
contiene el registro <T¡ comprometidax 

• Una transacción T¡ debe rehacerse si el registro 
histórico contiene los registros <T¡ iniciada> y 
<T¡ comprometidax 

Para ilustrarlo, considérese de nuevo el sistema ban- 
cario con la ejecución ordenada de las transacciones T 0 
y T u primero T 0 y después 7’,. Supóngase que el siste¬ 
ma cae antes de completarse las transacciones. Se con¬ 
siderarán tres casos. El estado del registro histórico para 
cada uno de ellos se muestra en la Figura 17.7. 

En primer lugar supóngase que la caída ocurre jus¬ 
to después de haber escrito en almacenamiento estable 
el registro del registro histórico para el paso 

escribir(5) 

de la transacción T 0 (Figura 17.7a). Cuando el siste¬ 
ma vuelve a funcionar encuentra en el registro histó¬ 
rico el registro <T 0 iniciada>, pero no su correspon¬ 
diente <T 0 comprometidax Por lo tanto, la transacción 
Jo debe deshacerse y se ejecutaría deshacer^). Como 
resultado de esta operación, los saldos de las cuentas 
Ay B (en el disco) se restituirían a 1.000 y 2.000 € 
respectivamente. 

Supóngase ahora que la caída sucede justo después 
de haber escrito en almacenamiento estable el registro 
del registro histórico para el paso 

escribir(C) 

de la transacción 7’, (Figura 17.7b). Cuando el sistema 
vuelve a funcionar, es necesario llevar a cabo dos accio¬ 
nes de recuperación. La operación deshacerf/j) debe 
ejecutarse porque en el registro histórico aparece el 
registro <T l iniciada>, pero no aparece <T l comprome¬ 
tidax La operación rehacer(7 0 ) debe ejecutarse porque 
el registro histórico contiene los registros <T 0 iniciada> 
y<T 0 comprometidax Al final del procedimiento de 
recuperación, los saldos de las cuentas A, B y C son de 


<T 0 iniciada> 
<7 0 ,A, 1000,950> 
<T 0 , B, 2000,2050> 


<T 0 ¡niciada> 

<T 0 ,A, 1000, 950> 
<7 0 , S, 2000, 2050> 
<T 0 comprometida> 
<T¡ iniciada> 

<7\, C, 700, 600> 


<T 0 ¡niciada> 

<7 0 ,A, 1000, 950> 
<T 0 , B, 2000, 2050> 
<T 0 comprometida> 
<T¡ ¡niciada> 

<T U C, 700, 600> 
<T, comprometida> 


(a) 


(b) 


(c) 


FIGURA 17.7. El mismo registro histórico mostrado en tres momentos distintos. 
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950,2.050 y 700 € respectivamente. Nótese que la ope¬ 
ración deshacer(7\) se ejecuta antes que rehacefiTg). 
En este ejemplo, el resultado sería el mismo si se cam¬ 
biara el orden. Sin embargo, el hecho de realizar pri¬ 
mero las operaciones deshacer y luego las operaciones 
rehacer es importante para el algoritmo de recupera¬ 
ción que se describe en el Apartado 17.6. 

Por último, supóngase que la caída tiene lugar justo 
después de haber escrito en almacenamiento estable el 
registro del registro histórico 

<T 1 comprometida> 

(Figura 17.7c). Cuando el sistema vuelve a funcionar, 
deben rehacerse tanto T 0 como T l ya que se encuen¬ 
tran en el registro histórico los registros <T 0 iniciada> 
y <T 0 comprometidas así como los registros <7j ini- 
ciada> y <T l comprometidax Los saldos de las cuen¬ 
tas A, B y C después de la ejecución de los procedi¬ 
mientos de recuperación rehacer(r o ) y rehacer(7j) se 
sitúan en 950, 2.050 y 600 € respectivamente. 

17.4.3. Puntos de revisión 

Cuando ocurre un fallo en el sistema se debe consultar 
el registro histórico para determinar las transacciones 
que deben rehacerse y las que deben deshacerse. En 
principio es necesario recorrer completamente el regis¬ 
tro histórico para hallar esta información. En este enfo¬ 
que hay dos inconvenientes principales: 

1. El proceso de búsqueda consume tiempo. 

2. La mayoría de las transacciones que deben reha¬ 
cerse de acuerdo con el algoritmo ya tienen escri¬ 
tas sus actualizaciones en la base de datos. Aunque 
el hecho de volver a ejecutar estas transacciones 
no produzca resultados erróneos, sí repercutirá en 
un aumento del tiempo de ejecución del proceso 
de recuperación. 

Para reducir este tipo de sobrecarga se introducen los 
puntos de revisión. Durante la ejecución, el sistema 
actualiza el registro histórico utilizando una de las dos 
técnicas que se describen en los Apartados 17.4.1 y 
17.4.2. Además, el sistema realiza periódicamente pun¬ 
tos de revisión, en los cuales tiene lugar la siguiente 
secuencia de acciones: 

1. Escritura en almacenamiento estable de todos los 
registros del registro histórico que residan en ese 
momento en memoria principal. 

2. Escritura en disco de todos los bloques de memo¬ 
ria intermedia que se hayan modificado. 

3. Escritura en almacenamiento estable de un regis¬ 
tro del registro histórico <revisión>. 

Mientras se lleva a cabo un punto de revisión no se 
permite que ninguna transacción realice acciones de 


actualización, tales como escribir en un bloque de me¬ 
moria intermedia o escribir un registro del registro his¬ 
tórico. 

La presencia de un registro <revisión> en el registro 
histórico permite que el sistema pueda hacer más efi¬ 
ciente su procedimiento de recuperación. Considérese 
una transacción T¡ que se comprometió antes del punto 
de revisión. Para esa transacción el registro <T¡ com- 
prometida> aparece en el registro histórico antes que el 
registro <revisión>. Todas las modificaciones sobre la 
base de datos hechas por T¡ se deben haber escrito en la 
base de datos antes del punto de revisión o formando 
parte del propio punto de revisión. Así, en el momento 
de la recuperación, no es necesario ejecutar una opera¬ 
ción rehacer sobre T¡. 

Esta observación permite perfeccionar los esquemas 
anteriores de recuperación (sigue siendo válido el 
supuesto de que las transacciones se ejecutan secuen- 
cialmente). Cuando se produce un fallo, el esquema de 
recuperación examina el registro histórico para deter¬ 
minar la última transacción T¡ que comenzó su ejecu¬ 
ción antes de que tuviera lugar el último punto de revi¬ 
sión. Para encontrar una transacción de este tipo se 
recorre el registro histórico hacia atrás, esto es, se empie¬ 
za a buscar por el final del registro histórico hasta que 
se encuentra el primer registro <revisión> (como se va 
recorriendo el registro histórico hacia atrás, el registro 
encontrado corresponde al último registro <revisión> 
del registro histórico); después se continúa la búsque¬ 
da hacia atrás hasta que se encuentra el siguiente regis¬ 
tro <T¡ iniciadax Este registro identifica a la transac¬ 
ción T¡. 

Una vez que ha sido identificada la transacción 
T¡ sólo es necesario aplicar las operaciones rehacer y 
deshacer a la transacción T¡ y a las transacciones 7j 
que comenzaron su ejecución después que T¡. Sea 
T este conjunto de transacciones. Puede ignorarse el 
resto del registro histórico (la parte del principio) y 
puede borrarse cuando se desee. El conjunto exacto 
de operaciones de recuperación que han de llevarse a 
cabo depende de si se está usando la técnica de mo¬ 
dificación inmediata o la de modificación diferida. 
Si se emplea la técnica de modificación inmediata, 
las operaciones de recuperación deben ser las siguien¬ 
tes: 

• Ejecutar deshacer) 7)) para todas las transacciones 
T k de T para las que no exista un registro <T k com- 
prometida> en el registro histórico. 

• Ejecutar rehacer)^.) para todas las transacciones 
T k de T para las que aparece un registro <T, com- 
prometida> en el registro histórico. 

Obviamente no es necesario aplicar la operación reha¬ 
cer cuando se está utilizando la técnica de modificación 
diferida. 

Como ejemplo considérese el conjunto de transac¬ 
ciones jr 0 , 7) ,..., de modo que su ejecución se 
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produce en el orden determinado por los subíndices. 
Supóngase que el último punto de revisión tiene lugar 
durante la ejecución de la transacción T 61 . Así, duran¬ 
te el esquema de recuperación, sólo deben considerar¬ 
se las transacciones T 67 , T 6S r i00 . Será necesario 


rehacer cada una de ellas si éstas se comprometieron y 
será necesario deshacerlas en caso contrario. 

En el Apartado 17.6.3 se estudia una extensión de la 
técnica de puntos de revisión para el procesamiento con¬ 
currente de transacciones. 


17.5. PAGINACIÓN EN LA SOMBRA 


La paginación en la sombra es una técnica de recupe¬ 
ración alternativa a las basadas en registro histórico. La 
técnica de paginación en la sombra es esencialmente la 
técnica de copia en la sombra que se vio en el Aparta¬ 
do 13.3 con algunas mejoras. Bajo ciertas circunstan¬ 
cias la paginación en la sombra puede requerir menos 
accesos al disco que los métodos basados en registro 
histórico que se presentaron anteriormente. No obstan¬ 
te, como se verá, existen algunos inconvenientes en el 
enfoque de la paginación en la sombra. Por ejemplo, es 
difícil extender la paginación en la sombra para permi¬ 
tir que varias transacciones puedan ejecutarse concu¬ 
rrentemente. 

Igual que antes, la base de datos se divide en un 
número determinado de bloques de longitud fija a los 
que se denominará páginas. Debido a que se va a uti¬ 
lizar un esquema de paginación para la gestión de la 
memoria, se ha tomado prestado de los sistemas opera¬ 
tivos el término página. Supóngase que hay n páginas 
numeradas desde 1 hasta n (en la práctica, n puede ser 
del orden de cientos de miles). No es necesario alma¬ 
cenar en disco estas páginas en un orden determinado 
(como se vio en el Capítulo 11 hay muchas razones por 
las que esto es así). Sin embargo, dado un cierto i, debe 
existir una manera de localizar la página í-ésima de la 
base de datos. Para este propósito se usará una tabla de 
páginas como se muestra en la Ligura 17.8. La tabla de 
páginas tiene n entradas, una para cada página de la base 
de datos. Cada entrada contiene un puntero a una pági¬ 
na en el disco. La primera entrada contiene un puntero 
a la primera página de la base de datos, la segunda entra¬ 
da apunta a la segunda página y así sucesivamente. En 
el ejemplo de la Ligura 17.8 se muestra que el orden 
lógico de las páginas de la base de datos no tiene por 
qué coincidir con el orden físico en el que están alma¬ 
cenadas en el disco. 

La idea principal que subyace tras la paginación en 
la sombra es la de mantener dos tablas de páginas duran¬ 
te la vida de una transacción: la tabla de páginas actual 
y la tabla de páginas sombra. Estas dos tablas son idén¬ 
ticas cuando comienza una transacción. Mientras dura 
la transacción no se altera el contenido de la tabla de 
páginas sombra. Cuando una transacción realiza una 
operación escribir, la tabla actual de páginas puede sufrir 
algún cambio. Todas las operaciones entrada y salida 
usan la tabla actual de páginas para encontrar las pági¬ 
nas de la base de datos en el disco. 


Supóngase que la transacción realiza una operación 
escribir(X) y que X pertenece a la página í-ésima. La 
operación escribir se ejecutaría como sigue: 

1. Ejecutar entrada(A) si la página í-ésima (es decir, 
la página en la que se encuentra X) no está toda¬ 
vía en memoria principal. 

2. Si es la primera escritura que esta transacción rea¬ 
liza sobre la página í-ésima, modificar la tabla 
actual de páginas siguiendo estos pasos: 

a. Encontrar una página en el disco que no se 
haya utilizado. Normalmente, como vimos en 
el Capítulo 11, el sistema de bases de datos 
tiene acceso a una lista de páginas no utiliza¬ 
das (libres). 

b. Borrar la página encontrada en el paso ante¬ 
rior de la lista de marcos de página libres. 

c. Modificar la tabla actual de páginas de modo 
que la entrada í-ésima apunte a la página 
encontrada en el paso 2a. 

3. Asignar el valor de x } a A en la página de la memo¬ 
ria intermedia. 

Compárense las acciones que se acaban de ver para 
realizar una operación escribir con las que se descri¬ 
bieron en el Apartado 17.2. La única diferencia es que 
se ha añadido un nuevo paso. Los pasos 1 y 3 se corres¬ 
ponden con los pasos 1 y 2 del Apartado 17.2. El paso 
nuevo, el segundo, manipula la tabla actual de páginas. 
En la figura 17.9 se muestran las tablas actual y en la 
sombra para una transacción que está realizando una 
escritura en la cuarta página de una base de datos que 
tiene 10 páginas. 

Intuitivamente, el enfoque de la paginación en la 
sombra para recuperación se basa en almacenar la tabla 
de páginas sombra en almacenamiento no volátil, de 
modo que puede recuperarse el estado de la base de 
datos antes de la ejecución de una transacción en caso 
de producirse una caída del sistema o de que se aborta¬ 
se la transacción. La tabla actual de páginas se escribe 
en almacenamiento no volátil cuando la transacción se 
compromete. Entonces, la tabla actual de páginas se 
convierte en la nueva tabla de páginas sombra y se con¬ 
cede el permiso para la ejecución de la siguiente tran¬ 
sacción. El hecho de que la tabla de páginas sombra se 
guarde en almacenamiento no volátil tiene gran impor- 
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páginas en el disco 



FIGURA 17.8. Ejemplo de tabla de páginas. 


tancia debido a que proporciona el único medio para 
encontrar las páginas de la base de datos. La tabla actual 
de páginas puede almacenarse en memoria principal 
(soporte de almacenamiento volátil). Como el sistema 
utiliza la tabla de páginas sombra para recuperarse, no 
importa si la tabla actual de páginas se pierde en una 
caída del sistema. 

Es necesario que, después de una caída del sistema, 
sea posible encontrar en el disco la tabla de páginas som¬ 
bra para poder realizar con éxito el proceso de recupe¬ 
ración. Una manera sencilla de encontrarla es elegir un 


lugar determinado del almacenamiento estable para 
albergar las direcciones del disco en las que se encuen¬ 
tra la tabla de páginas sombra. Cuando el sistema vuel¬ 
ve a funcionar después de una caída, se copia la tabla 
de páginas sombra en memoria principal y se utiliza 
para el procesamiento de las siguientes transacciones. 
Está garantizado, por la definición de la operación escri¬ 
bir, que la tabla de páginas sombra apuntará a las pági¬ 
nas de la base de datos correspondientes al estado ante¬ 
rior a cualquier transacción que estuviera activa en el 
momento de la caída. De esta manera, los abortos son 
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FIGURA 17.9. Tablas de páginas actual y en la sombra. 


automáticos. A diferencia de los esquemas basados en 
registro histórico, no es necesario realizar ninguna ope¬ 
ración deshacer. 

Para comprometer una transacción se deben seguir 
estos pasos: 

1. Asegurarse de que se escriben en disco todas las 
páginas de la memoria intermedia que se encuen¬ 
tren en memoria principal y que hayan sido modi¬ 
ficadas por la transacción. (Nótese que estas ope¬ 
raciones de escritura en disco no cambiarán las 
páginas de la base de datos que son apuntadas por 
las entradas de la tabla de páginas sombra.) 

2. Escribir en disco la tabla actual de páginas. No se 
debe sobreescribir la tabla de páginas sombra pues 
puede ser necesaria para el proceso de recupera¬ 
ción si ocurriera una caída. 

3. Escribir las direcciones del disco correspondien¬ 
tes a la tabla actual de páginas en el lugar del alma¬ 


cenamiento estable que contiene la dirección de 
la tabla de páginas sombra. Esta acción sobrees¬ 
cribe las direcciones de la anterior tabla de pági¬ 
nas sombra. Por lo tanto, la tabla actual es ahora 
la tabla en la sombra y la transacción se compro¬ 
mete. 

Si se produce una caída del sistema antes de la fina¬ 
lización del paso 3, se vuelve al estado inmediatamen¬ 
te anterior a la ejecución de la transacción. Si la caída 
sucede después de completar el paso 3, se conservarán 
los efectos de la transacción; no es necesario realizar 
ninguna operación rehacer. 

La paginación en la sombra presenta varias ventajas 
frente a las técnicas basadas en registro histórico. Se eli¬ 
mina la sobrecarga de escrituras del registro histórico y 
la recuperación es notablemente más rápida (ya que no 
son necesarias las operaciones rehacer ni deshacer). 
Sin embargo, la técnica de paginación en la sombra tam¬ 
bién tiene ciertos inconvenientes: 
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• Sobrecarga en el compromiso. Comprometer una 
sola transacción que utilice paginación en la som¬ 
bra precisa la escritura de muchos bloques: los blo¬ 
ques de datos reales, la tabla actual de páginas y 
las direcciones del disco de la tabla actual de pági¬ 
nas. Los esquemas basados en registro histórico 
sólo necesitan escribir los registros del registro his¬ 
tórico, los cuales, para pequeñas transacciones típi¬ 
cas, caben en un solo bloque. 

La sobrecarga de la escritura de una tabla de 
páginas completa se puede reducir implementan- 
do la tabla de páginas como una estmctura de árbol 
con las tablas de páginas en las hojas. A continua¬ 
ción se esboza esta técnica, dejando al lector que 
complete los detalles ausentes. Los nodos del árbol 
son páginas y tienen un alto grado de salida, como 
los árboles B + . El árbol de la tabla de páginas actual 
es inicialmente el mismo que el árbol de la tablas 
de páginas sombra. Cuando se actualiza por pri¬ 
mera vez una página, el sistema cambia la entrada 
de la tabla de páginas actual para que apunte a la 
copia de la página. Si la página hoja que contiene 
la entrada ya se ha copiado, el sistema lo actualiza 
directamente. En caso contrario, el sistema prime¬ 
ro lo copia y actualiza la copia. A su vez, es nece¬ 
sario actualizar el padre de la página copiada para 
que apunte a la nueva copia, lo que se realiza apli¬ 
cando el mismo procedimiento a su padre, copián¬ 
dolo si aún no se hubiese hecho. El proceso de la 
copia se realiza hasta la raíz del árbol. Los cambios 
sólo se hacen sobre los nodos copiados, así que el 
árbol de la tabla de páginas no se modifica. 

La ventaja de la representación de árbol es que 
sólo es necesario copiar las páginas hoja que hayan 
sido actualizadas, y todos sus ascendientes en el 
árbol. El resto de partes del árbol se comparten 
entre la página de tablas sombra y la actual, y no 
es necesario copiarlas. La reducción de los costes 
de copia puede ser significativa en grandes bases 
de datos. Sin embargo, aún es necesario copiar 
varias páginas de la tabla de páginas para cada tran¬ 
sacción, y los esquemas basados en registro his¬ 
tórico continúan siendo superiores siempre que las 
transacciones actualizan sólo pequeñas partes de 
la base de datos. 

• Fragmentación de datos. En el Capítulo 11 se 
consideraban ciertas estrategias para asegurar la 


localidad, es decir, mantener físicamente cercanas 
en el disco las páginas de la base de datos que esta¬ 
ban relacionadas entre sí. Esta localidad permite 
transferencias de datos más veloces. La pagina¬ 
ción en la sombra hace que las páginas de la base 
de datos cambien su ubicación en el disco siem¬ 
pre que se modifiquen. Como consecuencia, o se 
pierde la propiedad de localidad de las páginas o 
debe acudirse a esquemas de gestión del almace¬ 
namiento físico más complicados y con mayor 
sobrecarga (véanse las notas bibliográficas para 
obtener más información). 

• Recogida de basura. Cada vez que se compromete 
una transacción, las páginas de la base de datos que 
contenían la versión anterior de los datos y que fue¬ 
ron modificadas por la transacción se hacen inac¬ 
cesibles. En la Figura 17.9, cuando la transacción 
del ejemplo se comprometa, la página apuntada por 
la cuarta entrada de la tabla de páginas sombra pasa¬ 
rá a ser inaccesible. Las páginas como ésa son con¬ 
sideradas como basura debido a que no forman 
parte del espacio libre y no contienen ninguna infor¬ 
mación útil. Puede producirse basura también como 
efecto lateral de las caídas. Es necesario encontrar 
periódicamente todas las páginas basura para aña¬ 
dirlas a la lista de páginas libres. Este proceso, deno¬ 
minado recogida de basura, añade al sistema 
sobrecarga y complejidad. Existen varios algorit¬ 
mos estándar para la recogida de basura (véanse las 
referencias en las notas bibliográficas). 

Además de los inconvenientes que se acaban de 
mencionar, la paginación en la sombra presenta más 
dificultades que las técnicas basadas en registro histó¬ 
rico para adaptarla a sistemas que permitan la ejecu¬ 
ción concurrente de varias transacciones. En estos sis¬ 
temas, aunque se utilice la paginación en la sombra, 
suele ser necesaria alguna técnica basada en registro 
histórico. El prototipo System R, por ejemplo, utiliza 
una combinación de paginación en la sombra y un 
esquema basado en registro histórico similar al pre¬ 
sentado en el Apartado 17.4.2. Como se verá en el Apar¬ 
tado 17.6, es relativamente sencillo extender los esque¬ 
mas de recuperación basados en registro histórico para 
permitir transacciones concurrentes. Por todas estas 
razones no está muy extendido el uso de la paginación 
en la sombra. 


17.6. TRANSACCIONES CONCURRENTES Y RECUPERACIÓN 


Hasta ahora se ha tratado la recuperación en un entor¬ 
no en el que se ejecutaba una sola transacción en cada 
instante. Ahora se verá cómo modificar y extender el 
esquema de recuperación basado en registro histórico 
para permitir la ejecución concurrente de varias tran¬ 


sacciones. El sistema sigue teniendo una única memo¬ 
ria intermedia de disco y un único registro histórico 
independientemente del número de transacciones con¬ 
currentes. Todas las transacciones comparten los blo¬ 
ques de la memoria intermedia. Se permiten actualiza- 
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dones inmediatas y que un bloque de la memoria inter¬ 
media tenga elementos de datos que hayan sido modi¬ 
ficados por una o más transacciones. 

17.6.1. Interacción con el control 
de concurrencia 

El esquema recuperación depende en gran medida del 
esquema de control de concurrencia que se use. Para 
retroceder los efectos de una transacción fallida deben 
deshacerse las modificaciones realizadas por esa tran¬ 
sacción. Supóngase que se debe retroceder una tran¬ 
sacción T 0 y que un dato Q, que fue modificado por T 0 , 
tiene que recuperar su antiguo valor. Si se está usando 
un esquema basado en registro histórico para la recu¬ 
peración, es posible restablecer el valor de Q utilizan¬ 
do la información contenida en el registro histórico. 
Supóngase ahora que una segunda transacción Tj reali¬ 
za una nueva modificación sobre Q antes de retroceder 
T 0 . En este caso, al retroceder T 0 , se perdería la modifi¬ 
cación realizada por 7j. 

Es necesario, por tanto, que si una transacción T 
modifica el valor de un elemento de datos Q, ninguna 
otra transacción pueda modificar el mismo elemento de 
datos hasta que T se haya comprometido o se haya retro¬ 
cedido. Este requisito puede satisfacerse fácilmente uti¬ 
lizando bloqueo estricto de dos fases, esto es, bloqueo 
de dos fases manteniendo bloqueos exclusivos hasta el 
final de la transacción. 

17.6.2. Retroceso de transacciones 

Se utiliza el registro histórico para retroceder una tran¬ 
sacción T¡ fallida. El registro histórico se explora hacia 
atrás; para cada registro del registro histórico de la for¬ 
ma <T¡, Xj, V], V 2 >, se restablece el valor del elemento 
de datos Xj con su valor anterior: V¡. La exploración del 
registro histórico termina cuando se encuentra el regis¬ 
tro <T¡ iniciadax 

Es importante el hecho de recorrer el registro histó¬ 
rico empezando por el final, ya que una transacción pue¬ 
de haber actualizado más de una vez el valor de un ele¬ 
mento de datos. Como ejemplo, considérese este par de 
registros: 

<T¡,A, 10, 20> 

<T¡, A, 20, 30> 

Estos registros del registro histórico representan una 
modificación del elemento de datos A por parte de la 
transacción T¡, seguida de otra modificación de A hecha 
también por T¡. Al recorrer el registro histórico al revés 
se establece correctamente el valor de A como 10. Si el 
registro histórico se recorriera hacia delante, A tomaría 
como valor 20, lo cual es incorrecto. 

Si para el control de concurrencia se utiliza el blo¬ 
queo estricto de dos fases, los bloqueos llevados a cabo 
por una transacción T sólo pueden ser desbloqueados 


después de que la transacción se haya retrocedido según 
se acaba de describir. Una vez que T (que se está retro¬ 
cediendo) haya actualizado un elemento de datos, nin¬ 
guna otra transacción podría haber actualizado el mis¬ 
mo elemento de datos debido a los requisitos del control 
de concurrencia que se mencionaron en el apartado 
17.6.1. Así pues, la restitución del valor anterior de un 
elemento de datos no borrará los efectos de otra tran¬ 
sacción. 

17.6.3. Puntos de revisión 

En el Apartado 17.4.3 se usaban los puntos de revisión 
para reducir el número de registros del registro históri¬ 
co que debían ser examinados cuando el sistema se recu¬ 
peraba de una caída. Como se asumía que no existía la 
concurrencia, durante la recuperación era necesario con¬ 
siderar solamente las siguientes transacciones: 

• Las transacciones que comenzaron después del 
último punto de revisión 

• La única transacción, si la había, que estaba acti¬ 
va en el momento de grabarse el último punto de 
revisión 

Cuando las transacciones pueden ejecutarse con¬ 
currentemente, la situación se torna más complicada 
ya que varias transacciones pueden estar activas en el 
momento en que se produce el último punto de revi¬ 
sión. 

En un sistema de procesamiento de transacciones 
concurrente es necesario que el registro del registro his¬ 
tórico correspondiente a un punto de revisión sea de la 
forma <revisión L>, donde L es una lista con las tran¬ 
sacciones activas en el momento del punto de revisión. 
De nuevo se supone que, mientras que se realiza el pun¬ 
to de revisión, las transacciones no efectúan modifica¬ 
ciones ni sobre los bloques de la memoria intermedia 
ni sobre el registro histórico. 

El requisito de que las transacciones no puedan rea¬ 
lizar modificaciones sobre los bloques de la memoria 
intermedia ni sobre el registro histórico durante un pun¬ 
to de revisión puede resultar molesto, ya que el proce¬ 
samiento de transacciones tendrá que parar durante la 
ejecución de un punto de revisión. Un punto de revisión 
durante el cual se permite que las transacciones reali¬ 
cen modificaciones incluso mientras los bloques de 
memoria intermedia se están guardando en disco, se 
denomina punto de revisión difuso. En el Apartado 
17.9.5 se describen esquemas de revisión difusa. 

17.6.4. Recuperación al reiniciar 

El sistema construye dos listas cuando se recupera de 
una caída: la lista-deshacer, que consta de las tran¬ 
sacciones que han de deshacerse, y la lista-rehacer, 
que está formada por las transacciones que deben reha¬ 
cerse. 
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Estas dos listas se construyen durante la recupera¬ 
ción de la siguiente manera. Al principio ambas están 
vacías. Luego se recorre el registro histórico hacia atrás 
examinando cada registro hasta que se encuentra el pri¬ 
mer registro <revisión>: 

• Para cada registro encontrado de la forma <T¡ com¬ 
prometida^ se añade T¡ a la lista-rehacer. 

• Para cada registro encontrado de la forma <7j ini¬ 
ciada:^ si T¡ no está en la lista-rehacer, entonces 
se añade T¡ a la lista-deshacer. 

Una vez que se han examinado los registros apropiados 
del registro histórico, se atiende al contenido de la lis¬ 
ta L en el registro punto de revisión. Para cada transac¬ 
ción T¡ en L, si T¡ no está en la lista-rehacer, entonces 
se añade T¡ a la lista-deshacer. 

Cuando se terminan la lista-rehacer y la lista-des¬ 
hacer, el proceso de recuperación procede de la siguien¬ 
te manera: 

1. Se recorre de nuevo el registro histórico hacia 
atrás comenzando en el último registro y se rea¬ 
liza una operación deshacer por cada registro del 
registro histórico que pertenezca a una transac¬ 
ción T¡ de la lista-deshacer. En esta fase se igno¬ 
ran los registros del registro histórico concer¬ 
nientes a transacciones de la lista-rehacer. El 
recorrido del registro histórico termina cuando se 
encuentran registros <T¡ iniciada> para cada tran¬ 
sacción T¡ de la lista-deshacer. 

2. Se localiza el último registro <revis¡ón L> del 
registro histórico. Nótese que este paso puede 
necesitar de un recorrido del registro histórico 
hacia delante si el registro punto de revisión que¬ 
dó atrás en el paso 1. 

3. Se recorre el registro histórico hacia delante des¬ 
de el último registro <revisión L> y se realiza una 


operación rehacer por cada registro del registro 
histórico que pertenezca a una transacción T¡ de 
la lista-rehacer. En esta fase se ignoran los regis¬ 
tros del registro histórico concernientes a tran¬ 
sacciones de la lista-deshacer. 

Es importante procesar el registro histórico hacia 
atrás en el paso 1 para garantizar que el estado resul¬ 
tante de la base de datos sea correcto. 

Después de haber deshecho todas las transacciones 
de la lista-deshacer se rehacen aquellas transacciones 
que pertenezcan a la lista-rehacer. En este caso es 
importante procesar el registro histórico hacia delante. 
Cuando se ha completado el proceso de recuperación, 
se continúa con el procesamiento normal de las tran¬ 
sacciones. 

Es importante el hecho de deshacer las transac¬ 
ciones de la lista-deshacer antes de rehacer las tran¬ 
sacciones de la lista-rehacer al utilizar los pasos 1 a 
3 del algoritmo anterior. El siguiente problema podría 
ocurrir de no hacerse así. Supóngase que el elemen¬ 
to de datos A vale inicialmente 10. Supóngase tam¬ 
bién que una transacción T, modifica el valor de A 
situándolo en 20 y aborta a continuación; el retroce¬ 
so de la transacción devolvería a A el valor 10. Supón¬ 
gase que otra transacción T¡ cambia entonces a 30 el 
valor de A, se compromete y, seguidamente, el siste¬ 
ma cae. El estado del registro histórico en el momen¬ 
to de la caída es: 

<T¡, A, 10, 20> 

<T p A, 10, 30> 

<Tj comprometida> 

Si se rehace primero, A tomará el valor 30; y luego, 
al deshacer, A acabará valiendo 10, lo cual es incorrec¬ 
to. El valor final de A debe ser 30, lo que puede garan¬ 
tizarse si se deshace antes de rehacer. 


17.7. GESTIÓN DE LA MEMORIA INTERMEDIA 


En este apartado se consideran varios detalles sutiles 
que son esenciales para la implementación de un esque¬ 
ma de recuperación que garantice la consistencia de los 
datos y que lleve asociado una sobrecarga mínima res¬ 
pecto a la interacción con la base de datos. 

17.7.1. Registro histórico con memoria 
intermedia 

Anteriormente se supuso que se escribe cada registro 
del registro histórico en almacenamiento estable en el 
mismo momento de su creación. Esta suposición impo¬ 
ne una sobrecarga muy alta en la ejecución del sistema 
por las siguientes razones. Habitualmente, la unidad de 


escritura en almacenamiento estable es el bloque. En la 
mayoría de los casos un registro del registro histórico 
es mucho más pequeño que un bloque. Así, la escritu¬ 
ra de cada registro del registro histórico se traduce en 
una escritura mucho mayor en el nivel físico. Además 
de esto, como se vio en el Apartado 17.2.2, la escritura 
de un bloque en almacenamiento estable puede involu¬ 
crar varias operaciones de escritura en el nivel físico. 

El coste de realizar la escritura en almacenamiento 
estable de un bloque es suficientemente elevado para que 
sea deseable escribir de una sola vez varios registros del 
registro histórico. Para hacer esto se escriben los regis¬ 
tros del registro histórico en una memoria intermedia 
almacenada en la memoria principal en la que perma- 
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necen durante un tiempo hasta que se guardan en alma¬ 
cenamiento estable. Se pueden acumular varios regis¬ 
tros del registro histórico en la memoria intermedia del 
registro histórico y escribirse en almacenamiento esta¬ 
ble con una sola operación. El orden de los registros del 
registro histórico en el almacenamiento estable debe ser 
exactamente el mismo orden en el que fueron escritos 
en la memoria intermedia del registro histórico. 

Debido a la utilización de la memoria intermedia en 
el registro histórico, antes de ser escrito en almacena¬ 
miento estable, un registro del registro histórico puede 
permanecer únicamente en memoria principal (alma¬ 
cenamiento volátil) durante un espacio de tiempo con¬ 
siderable. Como esos registros se perderían si el siste¬ 
ma cayese, es necesaria la imposición de nuevos 
requisitos sobre las técnicas de recuperación para garan¬ 
tizar la atomicidad de las transacciones: 

• Después de que el registro <7j comprometida> se 
haya escrito en almacenamiento estable, la tran¬ 
sacción Tj pasa al estado comprometida. 

• Antes de escribir en almacenamiento estable el 
registro <7j comprometida^ todos los registros del 
registro histórico pertenecientes a la transacción 
Tj se deben escribir en almacenamiento estable. 

• Antes de que un bloque de datos en memoria prin¬ 
cipal se pueda escribir en la base de datos (en alma¬ 
cenamiento no volátil) todos los registros del regis¬ 
tro histórico pertenecientes a los datos de ese 
bloque se deben escribir en almacenamiento esta¬ 
ble. 

Esta última ligadura se denomina regla de regis¬ 
tro de escritura anticipada (REA). (Estricta¬ 
mente, la regla REA sólo necesita que haya sido 
puesta en almacenamiento estable la información 
concerniente a la operación deshacer y permite que 
la información relativa a la operación rehacer pue¬ 
da escribirse más tarde. La diferencia es relevan¬ 
te en aquellos sistemas en los que la información 
para rehacer y deshacer se guarda en registros del 
registro histórico independientes.) 

Las reglas anteriores representan situaciones en las que 
ciertos registros del registro histórico deben haber sido 
escritos en almacenamiento estable. No se produce nin¬ 
gún problema como resultado de la escritura de los regis¬ 
tros del registro histórico antes de que sea necesaria. 
Así, cuando el sistema decide que es necesario escribir 
en almacenamiento estable un registro del registro his¬ 
tórico, puede escribir un bloque entero de ellos si hay 
suficientes registros en memoria principal como para 
llenar un bloque. Si no hay suficientes registros para lle¬ 
nar el bloque, se forma un bloque parcialmente lleno 
con todos los registros que hubiera en memoria princi¬ 
pal y se ponen en almacenamiento estable. 

La escritura en disco de la memoria intermedia del 
registro histórico se denomina a veces forzar el regis¬ 
tro histórico. 


17.7.2. Base de datos con memoria intermedia 

En el Apartado 17.2 se describió el uso de una jerarquía 
de almacenamiento de dos niveles. La base de datos se 
almacena en almacenamiento no volátil (disco) y, cuan¬ 
do es necesario, se traen a memoria principal los blo¬ 
ques de datos que hagan falta. Como la memoria prin¬ 
cipal suele ser mucho más pequeña que la base de datos 
completa, puede ser necesaria la sobreescritura de un 
bloque B x en memoria principal cuando es necesario 
traer a memoria otro bloque B 2 . Si B , ha sido modifi¬ 
cado, B ! se debe escribir antes de traer B 2 . Como se dis¬ 
cutió en elApartado 11.5.1, en el Capítulo 11, esta jerar¬ 
quía de almacenamiento se corresponde con el concepto 
usual de memoria virtual. 

Las reglas que rigen la escritura de registros del regis¬ 
tro histórico limitan la libertad del sistema para escribir 
bloques de datos. Si la lectura del bloque B 2 provoca que 
el bloque B x tenga que escribirse en almacenamiento esta¬ 
ble, todos los registros del registro histórico pertenecien¬ 
tes a los datos de B x se deben escribir en almacenamien¬ 
to estable antes de la escritura de B x . Por tanto, la secuencia 
de acciones que ha de llevar a cabo el sistema sería ésta: 

• Escritura en almacenamiento estable de los regis¬ 
tros del registro histórico hasta que todos los regis¬ 
tros pertenecientes al bloque B x se hayan escrito. 

• Escritura en disco del bloque B x . 

• Lectura del bloque B 2 desde el disco a la memoria 
principal. 

Es un hecho importante el que no se produzcan escri¬ 
turas sobre el bloque B t mientras que se lleva a cabo la 
anterior secuencia de acciones. Esto puede garantizarse, 
como se explica a continuación, utilizando un medio de 
bloqueo especial. Antes de que una transacción realice 
una escritura sobre un elemento de datos debe adquirir 
un bloqueo en exclusiva sobre el bloque en el que resi¬ 
de el citado elemento de datos. Inmediatamente después 
de haber realizado la modificación, el bloqueo se puede 
liberar. Antes de la escritura de un bloque, el sistema 
obtiene un bloqueo exclusivo sobre ese bloque para ase¬ 
gurarse de que ninguna transacción está modificándolo. 
Una vez que la escritura del bloque se ha completado, el 
bloqueo se libera. Los bloqueos de corta duración se 
denominan con frecuencia pestillos. Los pestillos y los 
bloqueos utilizados por el sistema de control de concu¬ 
rrencia se tratan de forma diferente. Como resultado, los 
pestillos pueden liberarse sin necesidad de cumplir nin¬ 
gún protocolo de bloqueo, como el bloqueo de dos fases 
requerido por el sistema de control de concurrencia. 

Para ilustrar la necesidad del requisito de registro 
histórico con escritura anticipada considérese el ejem¬ 
plo bancario con las transacciones T 0 y 7j. Supóngase 
que el estado del registro histórico es 

<r 0 iniciada> 

<T 0 ,A, 1.000, 950> 
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y que la transacción T 0 realiza una operación leer(fi). 
Supóngase también que el bloque en el que se encuen¬ 
tra B no está en memoria principal y que esa memoria 
principal está llena. Supóngase por último que el blo¬ 
que en el que reside A es el elegido para la sustitución 
y, por tanto, ha de escribirse en disco. Si el sistema escri¬ 
be este bloque en disco y luego sucede una caída, los 
valores para las cuentas A, B y C en la base de datos son 
950, 2.000 y 700 € respectivamente. Este estado de la 
base de datos es inconsistente. Sin embargo, según los 
requisitos de la regla REA, el registro del registro his¬ 
tórico 

<T 0 ,A, 1.000, 950> 

debe escribirse en almacenamiento estable antes de pro¬ 
ducirse la escritura del bloque en el que se encuentra A. 
El sistema puede usar ese registro del registro históri¬ 
co durante la recuperación para devolver a la base de 
datos a un estado consistente. 

17.7.3. El papel del sistema operativo en la 
gestión de la memoria intermedia 

La memoria intermedia de la base de datos puede ges¬ 
tionarse usando uno de estos dos enfoques: 

1. El sistema de base de datos reserva parte de la 
memoria principal para utilizarla como memoria 
intermedia y es él, en vez del sistema operativo, 
el que se encarga de gestionarlo. El sistema de 
base de datos gestiona la transferencia de los blo¬ 
ques de datos de acuerdo con los requisitos del 
Apartado 17.7.2. 

El inconveniente de este enfoque es que limi¬ 
ta la flexibilidad en la utilización de la memoria 
principal. El tamaño de la memoria intermedia 
no debe ser muy grande para que otras aplica¬ 
ciones tengan suficiente espacio disponible en la 
memoria principal para sus propias necesidades. 
Sin embargo, incluso cuando ninguna otra apli¬ 
cación esté en ejecución, la base de datos no podrá 
hacer uso de toda la memoria disponible. Asi¬ 
mismo, aquellas aplicaciones que no tienen nada 
que ver con la base de datos no pueden usar la 
región de la memoria reservada para la memoria 
intermedia de la base de datos aunque no se estén 
utilizando algunas de las páginas almacenadas en 
la memoria intermedia. 

2. El sistema de base de datos implementa su memo¬ 
ria intermedia dentro de la memoria virtual del 
sistema operativo. Como el sistema operativo 
conoce las necesidades de memoria de todos los 
procesos del sistema, es lógico que pueda deci¬ 


dir los bloques de la memoria intermedia que 
deben escribirse al disco y el momento en el que 
debe realizarse esta escritura. Pero para garanti¬ 
zar los requisitos del registro histórico de escri¬ 
tura anticipada del Apartado 17.7.1, el sistema 
operativo no debería realizar él mismo la escri¬ 
tura de las páginas de la base de datos de la memo¬ 
ria intermedia, sino que debería pedírselo al sis¬ 
tema de base de datos para que fuera éste quien 
forzara la escritura de los bloques de la memoria 
intermedia. El sistema de base de datos, después 
de escribir en almacenamiento estable los regis¬ 
tros del registro histórico relevantes, forzaría la 
escritura en la base de datos de los bloques de la 
memoria intermedia. 

Por desgracia, casi todos los sistemas opera¬ 
tivos de la generación actual ejercen un control 
completo sobre la memoria virtual. El sistema 
operativo reserva espacio en el disco para alma¬ 
cenar las páginas de memoria virtual que no se 
encuentran en ese momento en la memoria prin¬ 
cipal; este espacio se denomina espacio de inter¬ 
cambio. Si el sistema operativo decide escribir 
un bloque B x , ese bloque se escribe en el espacio 
de intercambio del disco por lo que el sistema de 
base de datos no tiene forma de controlar la escri¬ 
tura de los bloques de la memoria intermedia. 

Por consiguiente, si la memoria intermedia de 
la base de datos está en la memoria virtual, las 
transferencias entre los archivos de la base de 
datos y la memoria intermedia en memoria vir¬ 
tual deben estar gestionadas por el sistema de base 
de datos, hecho que subraya el cumplimiento de 
los requisitos del registro histórico de escritura 
anticipada que se vieron. 

Este enfoque puede provocar una escritura adi¬ 
cional de datos en el disco. Si el sistema operati¬ 
vo realiza la escritura de un bloque B x , éste no se 
escribe en la base de datos sino que se escribe en 
el espacio de intercambio que utiliza la memoria 
virtual del sistema operativo. Cuando la base de 
datos necesita escribir B x , el sistema operativo 
puede necesitar primero leer B x de su espacio de 
intercambio. Así, en lugar de realizar una sola 
escritura de B x , son necesarias dos escrituras (una 
del sistema operativo y otra del sistema de base 
de datos) y una lectura adicional. 

Aunque ambos enfoques tienen algunos inconve¬ 
nientes, debe elegirse cualquiera de los dos excepto si 
el sistema operativo está diseñado para soportar los 
requisitos del registro histórico de base de datos. De los 
sistemas operativos actuales sólo unos pocos, como el 
sistema operativo Mach, soportan estos requisitos. 
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17.8. FALLO CON PÉRDIDA DE ALMACENAMIENTO NO VOLÁTIL 


Hasta ahora sólo se ha considerado el caso en el que un 
fallo conduce a la pérdida de información residente en 
almacenamiento volátil mientras que el contenido del 
almacenamiento no volátil permanecía intacto. A pesar 
de que es raro encontrarse con un fallo en el que se pier¬ 
da información de almacenamiento no volátil, es nece¬ 
sario prepararse para afrontar este tipo de fallos. En este 
apartado se hablará sólo del almacenamiento en disco. 
La argumentación puede aplicarse también a otras cla¬ 
ses de almacenamiento no volátil. 

La idea básica es volcar periódicamente (una vez al 
día) el contenido entero de la base de datos en almace¬ 
namiento estable. Por ejemplo, puede volcarse la base 
de datos en una o más cintas magnéticas. Se utilizará el 
volcado más reciente para que la base de datos recupe¬ 
re un estado consistente cuando ocurra un fallo que con¬ 
duzca a la pérdida de algunos bloques físicos de la base 
de datos. Una vez que se complete esta operación, el 
sistema utilizará el registro histórico para llevar al sis¬ 
tema de base de datos al último estado consistente en el 
que estuvo antes de producirse el fallo. 

Más precisamente, ninguna transacción puede estar 
activa durante el procedimiento de volcado y tendrá 
lugar una secuencia de acciones similar a la utilizada 
en los puntos de revisión: 

1. Escribir en almacenamiento estable todos los regis¬ 
tros del registro histórico que residan en ese 
momento en memoria principal. 

2. Escribir en disco todos los bloques de la memo¬ 
ria intermedia. 

3. Copiar el contenido de la base de datos en alma¬ 
cenamiento estable. 


4. Escribir el registro del registro histórico <revisión> 
en almacenamiento estable. 

Los pasos 1, 2 y 4 se corresponden con los tres pasos 
utilizados para realizar un punto de revisión en el Apar¬ 
tado 17.4.3. 

Para la recuperación por pérdida de almacenamien¬ 
to no volátil se restituye la base de datos en el disco uti¬ 
lizando el último volcado realizado. Entonces se con¬ 
sulta el registro histórico y se rehacen todas las 
transacciones que se hubieran comprometido desde que 
se efectuó ese último volcado. Nótese que no es nece¬ 
sario ejecutar ninguna operación deshacer. 

Un volcado del contenido de una base de datos se 
denomina también volcado de archivo ya que pueden 
archivarse los volcados y utilizarlos más tarde para exa¬ 
minar estados anteriores de la base de datos. Los vol¬ 
cados de una base de datos y la realización de puntos 
de revisión de las memorias intermedias son dos pro¬ 
cesos análogos. 

El procedimiento de volcado simple que se ha des¬ 
crito anteriormente es costoso debido a las dos razo¬ 
nes siguientes. En primer lugar, debe copiarse en alma¬ 
cenamiento estable la base de datos entera, lo que 
conlleva una considerable transferencia de datos. En 
segundo lugar, se pierden ciclos de UCP porque se 
detiene el procesamiento de transacciones durante el 
procedimiento de volcado. Se han desarrollado esque¬ 
mas de volcado difuso que permiten que las transac¬ 
ciones sigan activas mientras se realiza el volcado. Son 
esquemas similares a los de los puntos de revisión difu¬ 
sos. Para obtener más detalles véanse las notas biblio¬ 
gráficas. 


17.9. TÉCNICAS AVANZADAS DE RECUPERACIÓN** 


Las técnicas de recuperación descritas en el Apartado 
17.6 requieren que, una vez que una transacción modi¬ 
fica un elemento de datos, ninguna otra pueda modifi¬ 
car el mismo elemento de datos hasta que la primera se 
comprometa o se retroceda. Utilizando el bloqueo estric¬ 
to de dos fases se garantiza esa condición. Aunque el 
bloqueo estricto de dos fases es aceptable para los regis¬ 
tros en las relaciones, como se vio en el Apartado 16.9, 
provoca un decremento significativo en la concurren¬ 
cia cuando se aplica sobre determinadas estructuras, 
como las páginas indexadas con árboles B + . 

Para incrementar la concurrencia puede usarse el 
algoritmo de control de concurrencia en árboles B + des¬ 
crito en el Apartado 16.9 y así permitir que los bloqueos 
se liberen rápidamente, no con el procedimiento de dos 


fases. Como consecuencia, sin embargo, no serán apli¬ 
cables las técnicas de recuperación del Apartado 17.6. 
Se han propuesto varias técnicas de recuperación alter¬ 
nativas que pueden aplicarse incluso con bloqueos de 
liberación rápida. Estos esquemas se pueden usar en 
varias aplicaciones, no sólo para recuperar árboles B + . 
En primer lugar se describe un esquema de recupera¬ 
ción avanzado que soporta los bloqueos de liberación 
rápida. A continuación se describe el esquema de recu¬ 
peración ARIES, que se usa ampliamente en la indus¬ 
tria. ARIES es más complejo que el esquema de recu¬ 
peración avanzado descrito anteriormente, pero 
incorpora varias optimizaciones para minimizar el tiem¬ 
po de recuperación, y proporciona varias característi¬ 
cas útiles. 
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17.9.1. Registro de deshacer lógico 

En las operaciones donde los bloqueos son de libera¬ 
ción rápida no pueden realizarse las operaciones des¬ 
hacer escribiendo simplemente el valor anterior de los 
elementos de datos. Considérese una transacción T que 
inserta una entrada en un árbol B + y, siguiendo el pro¬ 
tocolo de control de concurrencia con árboles B + , libe¬ 
ra algunos bloqueos después de completarse la opera¬ 
ción inserción, pero antes de que la transacción se 
comprometa. Después de liberar los bloqueos, otras 
transacciones pueden realizar inserciones o borrados 
posteriores cambiando de este modo las páginas del 
árbol B + . 

Incluso aunque la operación libere rápidamente 
algunos bloqueos debe conservar suficientes bloqueos 
como para garantizar que ninguna otra transacción ten¬ 
ga permiso para ejecutar cualquier operación conflic¬ 
tiva (como leer o borrar el valor insertado). Por este 
motivo, el protocolo de control de concurrencia con 
árboles B + que se estudió anteriormente mantiene cier¬ 
tos bloqueos en las hojas del árbol B + hasta el final de 
la transacción. 

Considérese ahora cómo realizar retrocesos de tran¬ 
sacciones. Si se usa una operación deshacer física, es 
decir, si durante el retroceso se escriben los valores ante¬ 
riores de los nodos intemos del árbol B + (antes de eje¬ 
cutar la operación inserción), podrían perderse algunas 
de las modificaciones realizadas por inserciones o borra¬ 
dos ejecutados posteriormente por otras transacciones. 
La operación inserción no debe deshacerse así, sino con 
una operación deshacer lógica, esto es, mediante la eje¬ 
cución de una operación borrado en este caso. 

Así, cuando finaliza la acción de inserción, antes de 
que libere ningún bloqueo, escribe en el registro histó¬ 
rico un registro <T¡, Oj, fin-operación, D>, donde D 
denota la información para deshacer y 0¡ es un identi- 
ficador único de la operación. Por ejemplo, si la opera¬ 
ción insertó una entrada en el árbol B + , la información 
para deshacer indicaría lo que habría que borrar del árbol 
B + . Este registro histórico de información acerca de las 
operaciones se denomina registro histórico lógico. En 
cambio, el registro histórico de la información sobre el 
valor anterior y el nuevo valor se denomina registro 
histórico físico y los correspondientes registros del 
registro histórico se llaman registros del registro his¬ 
tórico físico. 

Las operaciones de inserción y borrado son ejemplos 
de un tipo de operaciones que requiere operaciones des¬ 
hacer lógicas, ya que liberan rápidamente los bloque¬ 
os. Estas operaciones se denominan operaciones lógi¬ 
cas. Antes de que una operación lógica dé comienzo, 
escribe en el registro histórico un registro <T¡ , O f , ini- 
cio-operación> donde Oj es el identificador único de la 
operación. Durante la ejecución de la operación se regis¬ 
tran todas las modificaciones realizadas por la opera¬ 
ción de forma normal. De esta manera se escribe para 
cada modificación la información habitual sobre el valor 


anterior y el nuevo valor. Al finalizar la operación se 
escribe en el registro histórico un registro de fin-opera¬ 
ción como se describió anteriormente. 

17.9.2. Retroceso de transacciones 

Considérese primero el retroceso de transacciones duran¬ 
te el modo de operación normal (esto es, no durante la 
fase de recuperación). Se recorre el registro histórico 
hacia atrás y se usan los registros del registro histórico 
pertenecientes a la transacción para devolver a los ele¬ 
mentos de datos sus valores anteriores. A diferencia del 
retroceso durante una operación normal, se escriben 
registros especiales sólo para la operación rehacer de la 
forma <7j, X¡, V> que contienen el valor V con el que 
se ha restaurado el elemento de datos X¡ durante el retro¬ 
ceso. Estos registros del registro histórico se denomi¬ 
nan a veces registros de compensación del registro 
histórico. Estos registros no necesitan información para 
deshacer puesto que nunca es necesario realizar esta 
operación. 

Se toman acciones especiales cuando se encuentra 
un registro del registro histórico de la forma <T¡, Oj, fin- 
operación, D>: 

1. Se retrocede la operación mediante la informa¬ 
ción para deshacer D que se encuentra en el regis¬ 
tro del registro histórico. Las modificaciones rea¬ 
lizadas durante el retroceso de la operación se 
registran de la misma manera que las modifica¬ 
ciones realizadas cuando la operación se ejecutó 
por primera vez. En otras palabras, el sistema 
registra información de deshacer física para las 
actualizaciones realizadas durante el retroceso, 
en lugar de usar registros de compensación del 
registro histórico. Esto es debido a que puede ocu¬ 
rrir una caída mientras la operación deshacer lógi¬ 
ca se encuentre en curso, y el sistema debe com¬ 
pletar durante la recuperación la operación 
deshacer lógica, usando la información deshacer 
física, y después realizar de nuevo la operación 
deshacer lógica, como se verá en el apartado 
17.9.4. 

Al final de la operación de retroceso, en lugar 
de generar un registro del registro histórico <T¡, 
0¡, fin-operación, D>, el sistema genera <T¡, Oj, 
abortar-operación, D>. 

2. Cuando continúa el recorrido hacia atrás del regis¬ 
tro histórico se ignoran todos los registros del 
registro histórico de la transacción hasta que se 
encuentra el registro <T¡, O •, inicio-operación>. 
Una vez que se encuentra en el registro histórico 
el registro inicio-operación se procesan de nuevo 
de manera normal los registros del registro his¬ 
tórico referentes a la transacción. 

Obsérvese que la omisión de los registros del registro 
histórico físico cuando se encuentra el registro fin-ope- 
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ración durante el retroceso asegura que los valores ante¬ 
riores del registro no se usen para el retroceso una vez 
que termine la operación. 

Si el sistema encuentra un registro <T¡, 0 - p abortar- 
operación, D>, omite todos los registros precedentes 
hasta que se encuentra el registro <T¡, C) p inicio-opera- 
ción>. Estos registros precedentes se deben omitir para 
evitar varios retrocesos de la misma operación en el caso 
de que haya una caída durante el retroceso anterior, y 
de que la transacción se haya retrocedido parcialmen¬ 
te. Cuando se haya retrocedido la transacción T¡, el sis¬ 
tema añade al registro <T¡ abortarx 

Si sucede un fallo mientras se está ejecutando una 
operación lógica, el registro fin-operación de la opera¬ 
ción no se encontrará cuando se retroceda la transac¬ 
ción. Sin embargo, para cada actualización realizada 
por la operación hay disponible en el registro histórico 
información para deshacer (como valor anterior en los 
registros del registro histórico físico). Los registros del 
registro histórico físico se usarán para retroceder la ope¬ 
ración incompleta. 

17.9.3. Puntos de revisión 

Los puntos de revisión se llevan a cabo como se des¬ 
cribió en el Apartado 17.6. Se suspenden temporalmente 
las modificaciones sobre la base de datos y se llevan a 
cabo las siguientes acciones: 

1. Se escriben en almacenamiento estable todos los 
registros del registro histórico que se encuentren 
en ese momento en la memoria principal. 

2. Se escriben en disco todos los bloques de la 
memoria intermedia que se hayan modificado. 

3. Se escribe en almacenamiento estable el registro 
<revisión L>, donde L es una lista de todas las 
transacciones activas. 

17.9.4. Recuperación al reiniciar 

Las acciones de recuperación se realizan en dos fases 
cuando se vuelve a iniciar el sistema de base de datos 
después de un fallo: 

1. En la fase rehacer se vuelven a realizar modifi¬ 
caciones de todas las transacciones mediante la 
exploración hacia delante del registro histórico a 
partir del último punto de revisión. Los registros 
del registro histórico que se vuelven a ejecutar 
incluyen los registros de transacciones que se 
retrocedieron antes de la caída del sistema y de 
las que no se habían comprometido cuando ocu¬ 
rrió la caída. Los registros del registro histórico 
son los registros habituales de la forma <T¡, X p 
V x , V 2 >, así como los registros especiales del regis¬ 
tro histórico de la forma <T¡, X¡, V 2 >; el elemen¬ 
to de datos X¡ adquiere el valor V 2 en cualquier 


caso. Esta fase también determina todas las tran¬ 
sacciones que o bien se encuentran en la lista de 
transacciones del registro del punto de revisión, 
o bien comenzaron más tarde, pero no tienen ni 
el registro <T¡ abortada> ni el registro <T¡ com- 
prometida> en el registro histórico. Todas estas 
transacciones deben retrocederse y sus identifi- 
cadores de transacción se ponen en una lista-des¬ 
hacer. 

2. En la fase deshacer se retroceden todas las tran¬ 
sacciones de la lista-deshacer. Se realiza el retro¬ 
ceso recorriendo el registro histórico hacia atrás 
empezando por el final. Cuando se encuentra un 
registro del registro histórico perteneciente a una 
transacción de la lista-deshacer se realizan las 
operaciones para deshacer de la misma manera 
que si el registro se hubiera encontrado durante 
el retroceso de una transacción fallida. Así pues, 
se ignoran los registros del registro histórico de 
una transacción que preceden a un registro fin- 
operación, pero que se encuentran detrás del 
correspondiente registro inicio-operación. 

Cuando se encuentra en el registro histórico 
un registro <T¡ iniciada> para una transacción T¡ 
de la lista-deshacer, se escribe en el registro his¬ 
tórico un registro <T¡ abortadax El recorrido 
hacia atrás del registro histórico finaliza cuando 
se encuentran los registros <T¡ iniciada> para todas 
las transacciones de la lista-deshacer. 

La fase rehacer de la recuperación al reiniciar repro¬ 
duce cada registro físico del registro histórico desde que 
tuvo lugar el último punto de revisión. En otras pala¬ 
bras, esta fase de la recuperación al reiniciar repite todas 
las acciones de modificación que fueron ejecutadas des¬ 
pués del punto de revisión y cuyos registros alcanzaron 
un registro histórico estable. Se incluyen aquí las accio¬ 
nes de transacciones incompletas y las acciones lleva¬ 
das a cabo para retroceder transacciones fallidas. Se 
repiten las acciones en el mismo orden en el que se lle¬ 
varon a cabo; de aquí que este proceso se denomine 
repetición de la historia. Al repetir la historia se sim¬ 
plifican bastante los esquemas de recuperación. 

Nótese que si una operación deshacer estaba en cur¬ 
so cuando ocurrió la caída del sistema, se encontrarían 
los registros del registro histórico físico escritos duran¬ 
te la operación deshacer, y la operación deshacer par¬ 
cial se desharía según estos registros del registro histó¬ 
rico físico. Después de ello, el registro fin-operación de 
la operación original se encontraría durante la recupe¬ 
ración, y la operación deshacer se ejecutaría de nuevo. 

17.9.5. Revisión difusa 

La revisión difusa descrita en el Apartado 17.6.3 requie¬ 
re que, mientras se efectúa el punto de revisión, se sus¬ 
pendan temporalmente todas las modificaciones de la 
base de datos. Si el número de páginas de la memoria 


432 


CAPÍTULO 17 SISTEMA DE RECUPERACIÓN 


intermedia es grande, un punto de revisión puede llevar 
mucho tiempo, lo que puede resultar en una interrup¬ 
ción inaceptable en el procesamiento de transacciones. 

Para evitar estas interrupciones es posible modificar 
la técnica para permitir modificaciones después de haber 
escrito en el registro histórico el registro revisión, pero 
antes de escribir en disco los bloques de la memoria 
intermedia que han sufrido modificaciones. El punto de 
revisión así generado recibe el nombre de punto de revi¬ 
sión difuso. 

Dado que las páginas se escriben en disco sólo des¬ 
pués de que se haya escrito el registro revisión, es posi¬ 
ble que el sistema caiga antes de que todas las páginas 
se hayan escrito. Por tanto, los puntos de revisión en 
disco pueden estar incompletos. Una forma de manejar 
los puntos de revisión incompletos es la siguiente. La 
ubicación del registro de revisión en el registro históri¬ 
co del último punto de revisión completado se almace¬ 
na en una posición fijada, el último punto de revisión, 
en disco. El sistema no actualiza esta información cuan¬ 
do escribe el registro revisión. En su lugar, antes de 
escribirlo, crea una lista de todos los bloques de memo¬ 
ria intermedia modificados. La información del último 
punto de revisión se actualiza sólo cuando todos los blo¬ 
ques de memoria intermedia de la lista de bloques modi¬ 
ficados se hayan escrito en disco. 

Incluso con la revisión difusa, un bloque de memo¬ 
ria intermedia no se debe actualizar mientras se esté 
escribiendo en disco, aunque otros bloques sí se pue¬ 
den actualizar concurrentemente. Una vez que todos los 
bloques han sido escritos en disco debe seguirse el pro¬ 
tocolo de registro histórico de escritura anticipada. 

Nótese que en este esquema sólo se utiliza el proce¬ 
so de registro histórico lógico para deshacer mientras 
que el proceso de registro histórico físico se usa tanto 
para deshacer como para rehacer. Existen otros esque¬ 
mas de recuperación que utilizan el proceso de registro 
histórico lógico para rehacer. Para deshacer lógicamente, 
el estado de la base de datos en disco debe ser consis¬ 
tente en cuanto a operaciones, es decir, no debería 
tener efectos parciales de ninguna operación. Es difícil 
garantizar esta consistencia de la base de datos en dis¬ 
co si una operación puede afectar a más de una página, 
puesto que no es posible escribir más de una página de 
forma atómica. Por tanto, el registro histórico deshacer 
lógico se restringe usualmente sólo a operaciones que 
afectan a una única página; se verá la forma de tratar 
estas operaciones rehacer lógicas en el Apartado 17.9.6. 
En cambio, las operaciones deshacer lógicas se reali¬ 
zan sobre un estado consistente en cuanto a operacio¬ 
nes de la base de datos repitiendo la historia y después 
realizando la operación deshacer física de las opera¬ 
ciones completadas parcialmente. 

17.9.6. ARIES 

El método de recuperación ARIES representa a los méto¬ 
dos actuales de recuperación. La técnica de recupera¬ 


ción avanzada que se ha descrito se ha modelado des¬ 
pués de ARIES, pero se ha simplificado significativa¬ 
mente para ilustrar los conceptos clave y hacerlo más 
fácil de comprender. En cambio, ARIES utiliza varias 
técnicas para reducir el tiempo de recuperación y para 
reducir la sobrecarga de los puntos de revisión. En par¬ 
ticular, ARIES es capaz de evitar rehacer muchas ope¬ 
raciones registradas que ya se han realizado y de redu¬ 
cir la cantidad de información registrada. El precio 
pagado es una mayor complejidad, pero los beneficios 
merecen la pena. 

Las diferencias principales entre ARIES y el algo¬ 
ritmo de recuperación avanzada expuesto son que 
ARIES: 

1. Usa un número de secuencia del registro his¬ 
tórico para identificar a los registros del registro 
histórico, y en el uso de estos números en las 
páginas de la base de datos para identificar las 
operaciones que se han realizado sobre una pági¬ 
na de la base de datos. 

2. Soporta operaciones rehacer fisiológicas, que son 
físicas en el sentido en que la página afectada está 
físicamente identificada, pero que pueden ser lógi¬ 
cas en la página. 

Por ejemplo, el borrado de un registro de una 
página puede resultar en que muchos otros regis¬ 
tros de la página se desplacen si se usa una estruc¬ 
tura de páginas con ranuras. Con el registro his¬ 
tórico rehacer físico, todos los bytes de la página 
afectada por el desplazamiento de los registros se 
deben registrar. Con el registro histórico fisioló¬ 
gico, la operación borrado se puede registrar, resul¬ 
tando en un registro mucho más pequeño. Al reha¬ 
cer la operación borrado se borraría el registro y 
se desplazarían los registros que fuese necesario. 

3. Usa una tabla de páginas desfasadas para mini¬ 
mizar las operaciones rehacer innecesarias duran¬ 
te la recuperación. Las páginas desfasadas son las 
que se han actualizado en memoria pero su ver¬ 
sión en disco no. 

4. Usa un esquema de revisión difusa que sólo regis¬ 
tra información sobre las páginas desfasadas e 
información asociada, y no requiere siquiera la 
escritura de las páginas desfasadas a disco. Pro¬ 
cesa las páginas desfasadas en segundo plano con¬ 
tinuamente, en lugar de escribirlas durante los 
puntos de revisión. 

En el resto de este apartado se proporciona una visión 
general de ARIES. Las notas bibliográficas listan refe¬ 
rencias que proporcionan una descripción completa de 
ARIES. 

17.9.6.1. Estructuras de datos 

Cada registro del registro histórico de ARIES tiene un 
número de secuencia del registro histórico (NSR) que 
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lo identifica unívocamente. El número es conceptual¬ 
mente tan sólo un identificador lógico cuyo valor es 
mayor para los registros que aparecen después en el 
registro histórico. En la práctica, el NSR se genera de 
forma que también se puede usar para localizar el regis¬ 
tro del registro histórico en disco. Normalmente, ARIES 
divide el registro histórico en varios archivos de regis¬ 
tro histórico, cada uno con un número de archivo. Cuan¬ 
do un archivo crece hasta un determinado límite, ARIES 
añade los nuevos registros del registro histórico en un 
nuevo archivo; el nuevo archivo de registro histórico 
tiene un número de archivo que es 1 mayor que el ante¬ 
rior archivo. El NSR consiste en un número de archivo 
y un desplazamiento dentro del archivo. 

Cada página también mantiene un identificador deno¬ 
minado NSRPágina. Cada vez que se aplica una ope¬ 
ración (física o lógica) en la página, la operación alma¬ 
cena el NSR de su registro en el campo NSRPágina de 
la página. Durante la fase rehacer de la recuperación 
cualquier registro con un NSR menor o igual que el 
NSRPágina de la página no se debería ejecutar, ya que 
sus acciones ya están reflejadas en la página. En com¬ 
binación con un esquema para el registro de los NSR¬ 
Página como parte de los puntos de revisión, que se pre¬ 
senta más adelante, ARIES puede evitar incluso leer 
muchas páginas cuyas operaciones registradas ya se han 
reflejado en el disco. Por tanto, el tiempo de recupera¬ 
ción se reduce significativamente. 

El NSRPágina es esencial para asegurar la idempo- 
tencia en presencia de operaciones rehacer fisiológicas, 
ya que volver a aplicar una operación rehacer fisiológi¬ 
ca que ya se haya aplicado a una página podría causar 
cambios incorrectos en una página. 

Las páginas no se deberían enviar a disco mientras 
se esté realizando una actualización, dado que las ope¬ 
raciones fisiológicas no se pueden rehacer sobre el esta¬ 
do parcialmente actualizado de la página en disco. Por 
tanto, ARIES usa pestillos sobre las páginas de la memo¬ 
ria intermedia para evitar que se escriban en disco mien¬ 
tras se actualicen. Los pestillos de las páginas de la 
memoria intermedia sólo se liberan cuando se comple¬ 
tan las actualizaciones, y el registro del registro histó¬ 
rico para la actualización se haya escrito en el registro 
histórico. 

Cada registro del registro histórico también contiene 
el NSR del registro anterior de la misma transacción. 
Este valor, almacenado en el campo NSRAnterior, per¬ 
mite que se encuentren los registros del registro históri¬ 
co anteriores sin necesidad de leer el registro histórico 
completo. En ARIES hay registros especiales sólo-reha- 
cer generados durante el retroceso de transacciones, 
denominados registros de compensación del registro 
histórico (RCR). Sirven para el mismo propósito que 
los registros sólo-rehacer del registro histórico del esque¬ 
ma de recuperación avanzado. Además juegan el papel 
de los registros abortar-operación de ese esquema. Los 
RCR tienen un campo extra denominado DeshacerSi- 
guienteNSR, que registra el NSR del registro que hay 


que deshacer a continuación cuando se retrocede la tran¬ 
sacción. Este campo sirve para el mismo propósito que 
el identificador de operaciones en el registro abortar-ope¬ 
ración del esquema anterior, que ayuda a omitir los regis¬ 
tros que ya se hayan retrocedido. La TablaPáginas- 
Desfasadas contiene una lista de páginas que se han 
actualizado en la memoria intermedia de la base de datos. 
Para cada página se almacena el NSRPágina y un cam¬ 
po denominado RegNSR que ayuda a identificar los 
registros que ya se han aplicado a la versión en disco de 
la página. Cuando se inserta una página en la TablaPá- 
ginasDesfasadas (cuando se modifica por primera vez 
en el grupo de memorias intermedias) el valor de 
RegNSR se establece en el fin actual del registro histó¬ 
rico. Cada vez que se envía una página a disco, la pági¬ 
na se elimina de la TablaPáginasDesfasadas. 

El registro punto de revisión del registro históri¬ 
co contiene la TablaPáginasDesfasadas y una lista de 
transacciones activas. Para cada transacción, el registro 
punto de revisión del registro histórico también anota 
ÚltimoNSR, el NSR del último registro escrito por la 
transacción. Una posición fijada en disco también ano¬ 
ta el NSR del último registro punto de revisión del regis¬ 
tro histórico (completado). 

17.9.6.2. Algoritmo de recuperación 

ARIES recupera de una caída del sistema en tres fases: 

• Paso de análisis. Este paso determina las tran¬ 
sacciones que hay que deshacer, las páginas que 
están desfasadas en el momento de la caída y el 
NSR en el que debería comenzar el paso rehacer. 

• Paso rehacer. Este paso comienza en una posición 
determinada durante el análisis y realiza una ope¬ 
ración rehacer, repitiendo la historia, para llevar a 
la base de datos al estado anterior a la caída. 

• Paso deshacer. Este paso retrocede todas las tran¬ 
sacciones incompletas en el momento de la caída. 

Paso de análisis. El paso de análisis busca el último 
registro punto de revisión del registro histórico com¬ 
pletado y lee la TablaPáginasDesfasadas en este regis¬ 
tro. A continuación establece RehacerNSR al mínimo 
RegistroNSR de las páginas de TablaPáginasDesfasa¬ 
das. Si no hay páginas desfasadas, establece Reha¬ 
cerNSR al NSR del registro punto de revisión del regis¬ 
tro histórico. El paso rehacer comienza explorando el 
registro histórico desde RehacerNSR. Todos los regis¬ 
tros anteriores a este punto ya se han aplicado a las pági¬ 
nas de la base de datos en el disco. El paso de análisis 
establece inicialmente la lista de transacciones que se 
deben deshacer, lista-deshacer, a la lista de transaccio¬ 
nes en el registro punto de revisión del registro históri¬ 
co. El paso de análisis también lee del registro punto de 
revisión del registro histórico los NSR del último regis¬ 
tro del registro histórico de cada transacción de las lis¬ 
ta-deshacer. 
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El paso de análisis continúa examinando hacia delan¬ 
te desde el punto de revisión. Cada vez que encuentra 
un registro de una transacción que no esté en la lista- 
deshacer, añade la transacción a la lista-deshacer. Cada 
vez que encuentra un registro de fin de transacción, borra 
la transacción de la lista-deshacer. Todas las transac¬ 
ciones que queden en la lista-deshacer al final del aná¬ 
lisis se deben retroceder más tarde en el paso deshacer. 
El paso de análisis también almacena el último registro 
de cada transacción en la lista-deshacer, que se usa en 
el paso deshacer. 

El paso de análisis también actualiza TablaPáginas- 
Desfasadas cada vez que encuentra un registro del regis¬ 
tro histórico de la actualización de una página. Si la 
página no está en la TablaPáginasDesfasadas, el paso 
de análisis la añade a ella y establece el RegistroNSR 
de la página al NSR del registro. 

Paso rehacer. El paso rehacer repite la historia vol¬ 
viendo a ejecutar cada acción sobre una página que no 
se haya reflejado en disco. El paso rehacer examina el 
registro histórico hacia delante a partir de RehacerNSR. 
Cada vez que encuentra un registro actualizar realiza: 

1. Si la página no está en la TablaPáginasDesfasadas 
o el NSR del registro actualizar es menor que el 
RegistroNSR de la página de TablaPáginasDesfa¬ 
sadas, entonces el paso rehacer omite el registro. 

2. En caso contrario, el paso rehacer extrae la pági¬ 
na de disco y, si NSRPágina es menor que el NSR 
del registro, se rehace el registro. 

Nótese que si cualquiera de las comprobaciones son 
negativas, entonces los efectos del registro del registro 
histórico ya han aparecido en la página. Si la primera 
comprobación es negativa, ni siquiera es necesario extra¬ 
er la página de disco. 

Paso deshacer y retroceso de transacciones. El paso 
deshacer es relativamente simple. Realiza una explora¬ 
ción hacia atrás del registro histórico, deshaciendo todas 
las transacciones de la lista-deshacer. Si se encuentra 
un RCR, usa el campo DeshacerSiguienteNSR para omi¬ 
tir los registros que ya se hayan retrocedido. En caso 
contrario, usa el campo NSRAnterior del registro para 
encontrar el siguiente a deshacer. 

Cada vez que se usa un registro del registro históri¬ 
co para realizar una operación deshacer (para el retro¬ 


ceso de transacciones durante el procesamiento normal 
del retroceso o durante el reinicio del paso deshacer) el 
paso deshacer genera un RCR conteniendo la acción 
deshacer realizada (que debe ser fisiológica). Estable¬ 
ce DeshacerSiguienteNSR del RCR al valor NSRAn¬ 
terior del registro actualizar del registro histórico. 

17.9.6.3. Otras características 

Entre otras de las características que proporciona ARIES 
se encuentran: 

• Independencia de recuperación. Algunas pági¬ 
nas se pueden recuperar independientemente de 
otras, de forma que se pueden usar incluso cuan¬ 
do se estén recuperando otras. Si fallan algunas 
páginas del disco se pueden recuperar sin parar 
el procesamiento de transacciones en otras pági¬ 
nas. 

• Puntos de almacenamiento. Las transacciones 
pueden registrar puntos de almacenamiento y se 
pueden retroceder parcialmente hasta un punto de 
almacenamiento. Esto puede ser muy útil en el 
manejo de interbloqueos, dado que las transaccio¬ 
nes se pueden retroceder hasta un punto que per¬ 
mita la liberación de los bloqueos requeridos y lue¬ 
go reiniciarse desde ese punto. 

• Bloqueo de grano fino. El algoritmo de recupe¬ 
ración ARIES se puede usar con algoritmos de con¬ 
trol de concurrencia de mdices que permiten el blo¬ 
queo en el nivel de tupias de los mdices, en lugar 
del bloqueo en el nivel de las páginas, lo que 
aumenta significativamente la concurrencia. 

• Optimizaciones de recuperación. La TablaPági¬ 
nasDesfasadas se puede usar para preextraer pági¬ 
nas durante la operación rehacer, en lugar de extra¬ 
er una página sólo cuando el sistema encuentra un 
registro del registro histórico a aplicar a la página. 
La operación rehacer no válidos también es posi¬ 
ble. Esta operación se puede posponer sobre una 
página que se vaya a extraer del disco y realizar¬ 
se cuando se extraiga. Mientras tanto se pueden 
procesar otros registros. 

En resumen, el algoritmo ARIES es un algoritmo de 
recuperación actual que incorpora varias optimizacio¬ 
nes diseñadas para mejorar la concurrencia, reducir la 
sobrecarga por el registro histórico y reducir el tiempo 
de recuperación. 


17.10. SISTEMAS REMOTOS DE COPIAS DE SEGURIDAD 


Los sistemas tradicionales de procesamiento de tran¬ 
sacciones son sistemas centralizados o sistemas clien¬ 
te-servidor. Esos sistemas son vulnerables frente a desas¬ 
tres ambientales como el fuego, las inundaciones o los 


terremotos. Hay una necesidad creciente de sistemas de 
procesamiento de transacciones que ofrezcan una dis¬ 
ponibilidad elevada y que puedan funcionar pese a los 
desastres ambientales. Estos sistemas deben proporcio- 
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nar una disponibilidad elevada, es decir, el tiempo en 
que el sistema no es utilizable debe ser extremadamen¬ 
te pequeño. 

Se puede obtener una disponibilidad elevada reali¬ 
zando el procesamiento de transacciones en un solo sitio, 
denominado sitio principal, pero tener un sitio remo¬ 
to copia de seguridad, en el que se repliquen todos los 
datos del sitio principal. El sitio remoto copia de segu¬ 
ridad se denomina también a veces sitio secundario. El 
sitio remoto debe mantenerse sincronizado con el sitio 
principal, ya que las actualizaciones se realizan en el 
sitio principal. La sincronización se obtiene enviando 
todos los registros del registro histórico desde el sitio 
principal al sitio remoto copia de seguridad. El sitio 
remoto copia de seguridad debe hallarse físicamente 
separado del principal —por ejemplo, se puede ubicar 
en otra provincia— para que una catástrofe en el sitio 
principal no afecte al sitio remoto copia de seguridad. 
En la Figura 17.10 se muestra la arquitectura de los sis¬ 
temas remotos para copias de seguridad. 

Cuando falla el sitio principal, el sitio remoto copia 
de seguridad asume el procesamiento. En primer lugar, 
sin embargo, lleva a cabo la recuperación utilizando su 
copia (tal vez anticuada) de los datos del sitio principal 
y los registros del registro histórico recibidos del mis¬ 
mo. En realidad, el sitio remoto copia de seguridad lle¬ 
va a cabo acciones de recuperación que se hubieran lle¬ 
vado a cabo en el sitio principal cuando éste se hubiera 
recuperado. Se pueden utilizar los algoritmos estándar 
de recuperación para la recuperación en el sitio remoto 
copia de seguridad con pocas modificaciones. Una vez 
realizada la recuperación, el sitio remoto copia de segu¬ 
ridad comienza a procesar transacciones. 

La disponibilidad aumenta mucho en comparación 
con los sistemas con un solo sitio, dado que el sistema 
puede recuperarse aunque se pierdan todos los datos del 
sitio principal. El rendimiento de los sistemas remotos 
para copias de seguridad es mejor que el de los siste¬ 
mas distribuidos con compromiso de dos fases. 

Varios aspectos que deben abordarse al diseñar siste¬ 
mas remotos para copias de seguridad son los siguientes: 

• Detección de fallos. Al igual que en los protoco¬ 
los para el manejo de fallos en sistemas distribui¬ 


dos, es importante que el sistema remoto de copia 
de seguridad detecte que el sitio principal ha falla¬ 
do. El fallo de las líneas de comunicación puede 
hacer creer al sitio remoto copia de seguridad que 
el sitio principal ha fallado. Para evitar este pro¬ 
blema hay que mantener varios enlaces de comu¬ 
nicaciones con modos de fallo independientes entre 
el sitio principal y el sitio remoto copia de seguri¬ 
dad. Por ejemplo, además de la conexión de red 
puede haber otra conexión mediante módem por 
línea telefónica con servicio suministrado por dife¬ 
rentes compañías de telecomunicaciones. Estas 
conexiones pueden complementarse con la inter¬ 
vención manual de operadores, que se pueden 
comunicar por sistema telefónico. 

• Transferencia del control. Cuando el sitio prin¬ 
cipal falla, el sitio copia de seguridad asume el pro¬ 
cesamiento y se transforma en el nuevo sitio prin¬ 
cipal. Cuando el sitio principal original se recupera 
puede desempeñar el papel de sitio remoto copia 
de seguridad o volver a asumir el papel de sitio 
principal. En cualquiera de los casos, el sitio prin¬ 
cipal antiguo debe recibir un registro histórico de 
actualizaciones realizado por el sitio copia de segu¬ 
ridad mientras el sitio principal antiguo estaba fue¬ 
ra de servicio. 

La manera más sencilla de transferir el con¬ 
trol es que el sitio principal antiguo reciba el 
registro histórico de operaciones rehacer del sitio 
copia de seguridad antiguo y se ponga al día con 
las actualizaciones aplicándolas de manera local. 
El sitio principal antiguo puede entonces actuar 
como sitio remoto copia de seguridad. Si hay que 
devolver el control, el sitio remoto copia de segu¬ 
ridad antiguo puede simular que ha fallado, lo 
que da lugar a que el sitio principal antiguo asu¬ 
ma el control. 

• Tiempo de recuperación. Si el registro histórico 
del sitio remoto copia de seguridad se hace gran¬ 
de, la recuperación puede tardar mucho. El sitio 
remoto copia de seguridad puede procesar de 
manera periódica los registros rehacer del registro 
histórico que haya recibido y realizar un punto de 
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FIGURA 17.10. Arquitectura de los sistemas remotos de copias de seguridad. 
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revisión de manera que se puedan borrar las par¬ 
tes más antiguas del registro histórico. Como con¬ 
secuencia se puede reducir el retraso antes de que 
el sitio remoto copia de seguridad asuma el con¬ 
trol. 

Una configuración de relevo en caliente pue¬ 
de hacer la toma del control por el sitio copia de 
seguridad casi instantáneo. En esta configuración 
el sitio remoto copia de seguridad procesa los regis¬ 
tros rehacer del registro histórico según llegan, y 
aplica las actualizaciones de manera local. Tan 
pronto como se detecta el fallo del sitio principal, 
el sitio copia de seguridad completa la recupera¬ 
ción retrocediendo las transacciones incompletas 
y queda preparado para procesar las nuevas. 

• Tiempo de compromiso. Para asegurar que las 
actualizaciones de una transacción comprometida 
sean duraderas no se debe declarar comprometi¬ 
da una transacción hasta que sus registros del 
registro histórico hayan alcanzado el sitio copia de 
seguridad. Este retraso puede dar lugar a una espe¬ 
ra más prolongada para comprometer la transac¬ 
ción y, en consecuencia, algunos sistemas permi¬ 
ten grados inferiores de durabilidad. Los grados 
de durabilidad pueden clasificarse de la manera 
siguiente. 

- Uno seguro. Las transacciones se comprome¬ 
ten tan pronto como sus registros de compro¬ 
miso del registro histórico se escriben en un 
almacenamiento estable en el sitio principal. 

El problema de este esquema es que puede 
que las actualizaciones de una transacción com¬ 
prometida no hayan alcanzado el sitio copia de 
seguridad cuando éste asuma el control del pro¬ 
cesamiento. Por tanto, puede parecer que las 
actualizaciones se han perdido. Cuando se recu¬ 
pere el sitio principal, las actualizaciones per¬ 
didas no se pueden mezclar directamente, dado 
que pueden entrar en conflicto con actualiza¬ 
ciones posteriores llevadas a cabo en el sitio 
copia de seguridad. Por tanto, puede que se nece¬ 
site la intervención humana para devolver a la 
base de datos a un estado consistente. 

- Dos muy seguro. Las transacciones se com¬ 
prometen tan pronto como sus registros de com¬ 
promiso del registro histórico se escriben en un 


almacenamiento estable en el sitio principal y 
en el sitio copia de seguridad. 

El problema de este esquema es que el pro¬ 
cesamiento de transacciones no puede continuar 
si alguno de los puntos no está operativo. Por 
tanto, la disponibilidad es realmente menor que 
en el caso de un solo sitio, aunque la posibili¬ 
dad de la pérdida de datos es mucho más redu¬ 
cida. 

- Dos seguro. Este esquema es idéntico al esque¬ 
ma dos muy seguro si tanto el sitio principal 
como el sitio copia de seguridad están activos. 
Si sólo está activo el sitio principal se permite 
que la transacción se comprometa tan pronto 
como su registro de compromiso del registro 
histórico se escriba en un almacenamiento esta¬ 
ble en el sitio principal. 

Este esquema proporciona mejor disponibi¬ 
lidad que el esquema dos muy seguro al tiempo 
que evita el problema de las transacciones per¬ 
didas afrontado por el esquema uno seguro. Da 
lugar a un compromiso más lento que el esque¬ 
ma uno seguro pero las ventajas generalmente 
superan los inconvenientes. 

Varios sistemas comerciales de disco compartido pro¬ 
porcionan un nivel de tolerancia de fallos intermedio 
entre el de los sistemas centralizados y el de los siste¬ 
mas remotos para copias de seguridad. En estos siste¬ 
mas el fallo de una UCP no da lugar al fallo del siste¬ 
ma. En lugar de ello, otra UCP asume el control y lleva 
a cabo la recuperación. Las acciones de recuperación 
incluyen el retroceso de las transacciones que se ejecu¬ 
taban en la UCP que falló y la recuperación de los blo¬ 
queos mantenidos por dichas transacciones. Dado que 
los datos se hallan en un disco compartido, no hace fal¬ 
ta transferir registros del registro histórico. Sin embar¬ 
go, se deberían proteger los datos contra el fallo del dis¬ 
co utilizando, por ejemplo, una organización de discos 
RAID. 

Una forma alternativa de conseguir alta disponibili¬ 
dad es usar una base de datos distribuida con los datos 
replicados en más de un sitio. Son necesarias transac¬ 
ciones para actualizar todas las réplicas de cualquier 
elemento de datos que actualicen. Las bases de datos 
distribuidas, incluyendo la réplica, se estudian en el 
Capítulo 19. 


17.11. RESUMEN 


• Un sistema informático, al igual que cualquier otro 
dispositivo eléctrico o mecánico, está sujeto a fallos. 
Estos fallos se producen por diferentes motivos inclu¬ 
yendo fallos de disco, cortes de corriente o fallos en 
el software. En cada uno de estos casos puede per¬ 
derse información concerniente a la base de datos. 


• Las transacciones pueden fallar, además de por un fallo 
del sistema, por otras razones como una violación de 
las restricciones de integridad o interbloqueos. 

• El esquema de recuperación es una parte integrante 
del sistema de base de datos el cual es responsable de 
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la detección de fallos y del restablecimiento de un 
estado de la base datos anterior al momento de pro¬ 
ducirse el fallo. 

• Los diferentes tipos de almacenamiento en una com¬ 
putadora son el volátil, el no volátil y el almacena¬ 
miento estable. Los datos del almacenamiento volá¬ 
til, como ocurre con los guardados en la memoria 
RAM, se pierden cuando la computadora cae. Los 
datos del almacenamiento no volátil, como los guar¬ 
dados en un disco, no se pierden cuando la computa¬ 
dora cae, pero pueden perderse ocasionalmente debi¬ 
do a fallos de disco. Los datos del almacenamiento 
estable nunca se pierden. 

• El almacenamiento estable de acceso en tiempo real 
puede aproximarse con discos con imagen u otras for¬ 
mas de RAID que proporcionan almacenamiento 
redundante de datos. El almacenamiento estable, sin 
conexión o de archivo, puede consistir en una serie 
de copias en cinta de los datos guardadas en un lugar 
físicamente seguro. 

• El estado del sistema de base de datos puede no vol¬ 
ver a ser consistente en caso de ocurrir un fallo; esto 
es, puede no reflejar un estado del mundo potencial¬ 
mente alcanzable por la base de datos. Para preservar 
la consistencia es necesario que cada transacción sea 
atómica. Garantizar la propiedad de atomicidad es 
responsabilidad del esquema de recuperación. Exis¬ 
ten básicamente dos esquemas para garantizar la ato¬ 
micidad: basados en registro histórico y paginación 
en la sombra. 

• En los esquemas basados en registro histórico todas 
las modificaciones se escriben en el registro históri¬ 
co, el cual debe estar guardado en almacenamiento 
estable. 

— En el esquema de modificación diferida, durante 
la ejecución de una transacción, se difieren todas 
las operaciones escribir hasta que la transacción 
se compromete parcialmente, momento en el que 
se utiliza la información del registro histórico aso¬ 
ciada con la transacción para ejecutar las escritu¬ 
ras diferidas. 

— Con la técnica de modificación inmediata, todas 
las modificaciones se aplican directamente sobre 
la base de datos. Si ocurre una caída se utiliza la 
información del registro histórico para conducir 
a la base de datos a un estado estable previo. 

Puede usarse la técnica de los puntos de revisión para 
reducir la sobrecarga que conlleva la búsqueda en el 
registro histórico y rehacer las transacciones. 

• En la paginación en la sombra, durante la vida de una 
transacción se mantienen dos tablas de páginas: la 
tabla actual de páginas y la tabla de páginas sombra. 
Ambas tablas son idénticas cuando la transacción 
comienza. La tabla de páginas sombra y las tablas a 
las que apunta no sufren ningún cambio mientras dura 
la transacción. Cuando la transacción se comprome¬ 


te parcialmente se desecha la tabla de páginas som¬ 
bra y la tabla actual se convierte en la nueva tabla de 
páginas. Si la transacción aborta, simplemente se dese¬ 
cha la tabla actual de páginas. 

• La técnica de la paginación en la sombra no puede 
aplicarse si se permite que varias transacciones se eje¬ 
cuten concurrentemente, pero el esquema basado en 
registro histórico sí. 

No se permite que ninguna transacción pueda 
modificar un elemento de datos que ya se ha modifi¬ 
cado por una transacción incompleta. Para garantizar 
esta condición puede utilizarse el bloqueo estricto de 
dos fases. 

• El procesamiento de transacciones se basa en un 
modelo de almacenamiento en el que la memoria prin¬ 
cipal contiene una memoria intermedia para el regis¬ 
tro histórico, una memoria intermedia para la base de 
datos y una memoria intermedia para el sistema. La 
memoria intermedia del sistema alberga páginas de 
código objeto del sistema y áreas de trabajo local de 
las transacciones. 

• Una implementación eficiente de un esquema de recu¬ 
peración de datos requiere que el número de escritu¬ 
ras en la base de datos y en almacenamiento estable 
sea mínimo. Los registros del registro histórico pue¬ 
den guardarse inicialmente en la memoria intermedia 
del registro histórico en almacenamiento volátil, pero 
se deben copiar en almacenamiento estable cuando 
se da una de estas dos condiciones: 

— Deben escribirse en almacenamiento estable todos 
los registros del registro histórico pertenecientes 
a la transacción T¡ antes de que el registro <T¡ com- 
prometida> se pueda escribir en almacenamiento 
estable. 

— Deben escribirse en almacenamiento estable todos 
los registros del registro histórico pertenecientes 
a los datos de un bloque antes de que ese bloque 
de datos se escriba desde la memoria principal a 
la base de datos (en almacenamiento no volátil). 

• Para recuperarse de los fallos que resultan en la pér¬ 
dida de almacenamiento no volátil debe realizarse un 
volcado periódicamente (por ejemplo, una vez al día) 
del contenido entero de la base de datos en almace¬ 
namiento estable. Se usará el último volcado para 
devolver a la base de datos a un estado consistente 
previo cuando ocurra un fallo que conduzca a la pér¬ 
dida de algún bloque físico de la base de datos. Una 
vez realizada esta operación se utilizará el registro 
histórico para llevar a la base de datos al estado con¬ 
sistente más reciente. 

• Se han desarrollado técnicas avanzadas de recupera¬ 
ción para soportar técnicas de bloqueo de alta con¬ 
currencia, como las utilizadas para el control de con¬ 
currencia con árboles B + . Estas técnicas se basan en 
el registro deshacer lógico y siguen el principio de 
repetir la historia. En la recuperación de un fallo del 
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sistema se realiza una fase rehacer utilizando el regis¬ 
tro histórico seguida de una fase deshacer sobre el 
registro histórico para retroceder las transacciones 
incompletas. 

• El esquema de recuperación ARIES es un esquema 
actual que soporta varias características para propor¬ 
cionar mayor concurrencia, reducir la sobrecarga del 
registro histórico y permitir operaciones deshacer lógi¬ 
cas. El esquema procesa páginas continuamente y no 


necesita procesar todas las páginas en el momento de 
un punto de revisión. Usa números de secuencia del 
registro histórico (NSR) para implementar varias opti¬ 
mizaciones que reducen el tiempo de recuperación. 

• Los sistemas remotos de copia de seguridad propor¬ 
cionan un alto nivel de disponibilidad, permitiendo 
que continúe el procesamiento de transacciones inclu¬ 
so si se destruye el sitio primario por fuego, inunda¬ 
ción o terremoto. 


TÉRMINOS DE REPASO 


• Alta disponibilidad 

• ARIES 

- Número de secuencia del registro histórico (NSR) 

- NSRPágina 

- Operación rehacer fisiológica 

- Registros de compensación del registro histórico 
(RCR) 

- TablaPáginasDesfasadas 

- Registro punto de revisión 

• Bloques 

- Bloques físicos 

- Bloques de memoria intermedia 

• Clasificación de los fallos 

- Fallo de transacción 

- Error lógico 

- Error del sistema 

- Caída del sistema 

- Fallo de transferencia de datos 

• Configuración de relevo en caliente 

• Detección de fallos 

• Escritura forzada 

• Esquema de recuperación 

• Fallo de disco 

• Forzar el registro histórico 

• Gestión de la memoria intermedia 

• Idempotente 

• Memoria intermedia de la base de datos 

• Memoria intermedia de disco 

• Modificación diferida 

• Modificación inmediata 

• Modificaciones no comprometidas 

• Paginación en la sombra 

- Tabla de páginas 

- Tabla de páginas actual 

- Tabla de páginas sombra 


Pérdida del almacenamiento no volátil 
Pestillos 

Puntos de revisión 
Puntos de revisión difusos 
Recogida de basura 

Recuperación basada en el registro histórico 
Recuperación con transacciones concurrentes 

- Retroceso de transacciones 

- Puntos de revisión difusos 

- Recuperación al reiniciar 
Registro actualizar del registro histórico 
Registro de escritura anticipada (REA) 

Registro histórico 

Registro histórico con memoria intermedia 
Registros del registro histórico 
Repetición de la historia 

Sistema operativo y gestión de la memoria interme 
dia 

Sistemas remotos de copia de seguridad 

- Sitio principal 

- Sitio remoto copia de seguridad 

- Sitio secundario 
Supuesto de fallo-parada 
Técnica de recuperación avanzada 

- Operación deshacer física 

- Operación deshacer lógica 

- Registro histórico físico 

- Registro histórico lógico 

- Operaciones lógicas 

- Retroceso de transacciones 

- Puntos de revisión 

- Recuperación al reiniciar 

- Fase rehacer 

- Fase deshacer 
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Tiempo de compromiso 

- Uno seguro 

- Dos muy seguro 

- Dos seguro 
Tiempo de recuperación 
Tipos de almacenamiento 


- Almacenamiento volátil 

- Almacenamiento no volátil 

- Almacenamiento estable 
Transferencia del control 
Volcado de archivo 
Volcado difuso 


EJERCICIOS 


17.1. Expliqúese la diferencia en cuanto al coste entre los 
tres tipos de almacenamiento: volátil, no volátil y esta¬ 
ble. 

17.2. No se puede implementar el almacenamiento estable. 

a. Expliqúese por qué no. 

b. Expliqúese cómo tratan este problema los sistemas 
de las bases de datos. 

17.3. Compárense, en términos de facilidad de implemen- 
tación y de sobrecarga, las versiones de modificación 
inmediata y modificación diferida de las técnicas de 
recuperación basadas en registro histórico. 

17.4. Supóngase que un sistema utiliza modificación inme¬ 
diata. Demuéstrese, con un ejemplo, cómo podría dar¬ 
se un estado inconsistente en la base de datos si no se 
escriben en almacenamiento estable los registros del 
registro histórico de una transacción antes de que el 
dato actualizado por la transacción se escriba a disco. 

17.5. Expliqúese el propósito del mecanismo de los puntos 
de revisión. ¿Con qué frecuencia deberían realizarse 
los puntos de revisión? Expliqúese cómo afecta la fre¬ 
cuencia de los puntos de revisión: 

- Al rendimiento del sistema cuando no ocurre nin¬ 
gún fallo 

- Al tiempo que se tarda para recuperarse de una caí¬ 
da del sistema 

- Al tiempo que se tarda para recuperarse de una caí¬ 
da del disco 

17.6. Cuando el sistema se recupera después de una caída 
(véase el Apartado 17.6.4) construye una lista-des¬ 
hacer y una lista-rehacer. Expliqúese por qué deben 
procesarse en orden inverso los registros del registro 
histórico de las transacciones que se encuentran en la 
lista-deshacer, mientras que los registros del registro 
histórico correspondientes a las transacciones de la 
lista-rehacer se procesan hacia delante. 

17.7. Compárense, en términos de facilidad de implemen- 
tación y sobrecarga, el esquema de recuperación con 
paginación en la sombra con los esquemas de recu¬ 
peración basados en registro histórico. 

17.8. Considérese una base de datos compuesta por 10 blo¬ 
ques consecutivos en el disco (bloque 1, bloque 2,..., 
bloque 10). Muéstrese el estado de la memoria inter¬ 
media y una posible ordenación física de los bloques 
después de las siguientes modificaciones, suponien¬ 
do que se utiliza paginación en la sombra, que la 


memoria intermedia en memoria principal sólo pue¬ 
de albergar tres bloques y que se usa la estrategia 
menos recientemente utilizada para gestionar la 
memoria intermedia. 

leer bloque 3 
leer bloque 7 
leer bloque 5 
leer bloque 3 
leer bloque 1 
modificar bloque 1 
leer bloque 10 
modificar bloque 5 

17.9. Expliqúese cómo el gestor de la memoria intermedia 
puede conducir a la base de datos a un estado incon¬ 
sistente si algunos registros del registro histórico per¬ 
tenecientes a un bloque no se escriben en almacena¬ 
miento estable antes de escribir en el disco el citado 
bloque. 

17.10. Expliqúense las ventajas del registro histórico lógico. 
Proporciónense ejemplos de una situación en la que 
sea preferible el registro histórico lógico frente al regis¬ 
tro histórico físico y de una situación en la que sea 
preferible el registro histórico físico al registro histó¬ 
rico lógico. 

17.11. Expliqúense las razones por las que la recuperación 
en transacciones interactivas es más difícil de tratar 
que la recuperación en transacciones por lotes. ¿Exis¬ 
te una forma simple de tratar esta dificultad? ( Suge¬ 
rencia: considérese una transacción de un cajero auto¬ 
mático por la que se retira dinero.) 

17.12. A veces hay que deshacer una transacción después de 
que se haya comprometido porque se ejecutó erró¬ 
neamente, debido por ejemplo a la introducción inco¬ 
rrecta de datos de un cajero. 

a. Dese un ejemplo para demostrar que el uso de un 
mecanismo normal para deshacer esta transacción 
podría conducir a un estado inconsistente. 

b. Una forma de manejar esta situación es llevar la base 
de datos a un estado anterior al compromiso de la 
transacción errónea (denominado recuperación a un 
instante). En este esquema se deshacen los efectos 
de las transacciones comprometidas después. 

Sugiérase una modificación del mecanismo de 
recuperación avanzada para implementar la recu¬ 
peración a un instante. 
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c. Las transacciones correctas se pueden volver a eje¬ 
cutar lógicamente, pero no se pueden reejecutar 
usando sus registros del registro histórico. ¿Por qué? 

17 . 13 . En los lenguajes de programación persistentes no se 
realiza explícitamente el registro histórico de las modi¬ 
ficaciones. Descríbase cómo pueden usarse las pro¬ 
tecciones de acceso a las páginas que proporcionan 
los sistemas operativos modernos para crear imáge¬ 
nes anteriores y posteriores de las páginas que son 
modificadas. ( Sugerencia : véase el Ejercicio 16.12.) 

17 . 14 . ARIES asume que hay espacio en cada página para 
un NSR. Al manejar objetos grandes que abarcan 
varias páginas, tales como archivos del sistema ope¬ 
rativo, un objeto puede usar una página completa, sin 
dejar espacio para el NSR. Sugiérase una técnica para 
manejar esta situación; esta técnica debe soportar ope¬ 


raciones rehacer físicas pero no es necesario que 
soporte operaciones rehacer fisiológicas. 

17 . 15 . Expliqúese la diferencia entre una caída del sistema 
y un «desastre». 

17 . 16 . Para cada uno de los siguientes requisitos identifi¬ 
qúese la mejor opción del grado de durabilidad en un 
sistema remoto de copia de seguridad. 

a. Pérdida de datos que se debe evitar pero se puede 
tolerar alguna pérdida de disponibilidad. 

b. El compromiso de transacciones se debe realizar 
rápidamente, incluso perdiendo algunas transac¬ 
ciones comprometidas en caso de desastre. 

c. Se requiere un alto grado de disponibilidad y dura¬ 
bilidad, pero es aceptable un mayor tiempo de eje¬ 
cución para el protocolo de compromiso de tran¬ 
sacciones. 


NOTAS BIBLIOGRÁFICAS 


El libro de Gray y Reuter [1993] constituye una exce¬ 
lente fuente de información sobre la recuperación inclu¬ 
yendo interesantes implementaciones y detalles histó¬ 
ricos. El libro de Bernstein et al. [1987] es una fuente 
de información sobre el control de concurrencia y recu¬ 
peración. 

Davies [1973] y Bjork [1973] son dos de los prime¬ 
ros documentos que presentan trabajos teóricos en el 
campo de la recuperación. Otro trabajo pionero en este 
campo es el de Chandy et al. [1975], el cual describe 
modelos analíticos para el retroceso y las estrategias de 
recuperación en los sistemas de bases de datos. 

En Gray et al. [1981b] se presenta una visión de con¬ 
junto del esquema de recuperación de System R. El 
mecanismo de paginación en la sombra de System R se 
describe en Lorie [1977]. En Gray [1978], Lindsay et 
al. [1980] y Verhofstad [1978] pueden encontrarse guías 
de aprendizaje y visiones de conjunto sobre varias téc¬ 
nicas de recuperación para sistemas de bases de datos. 
Los conceptos de punto de revisión difuso y volcado 
difuso se describen en Lindsay et al. [1980]. Haerder y 
Reuter [1983] ofrece una amplia presentación de los 
principios de la recuperación. 


El estado del arte de los métodos de recuperación se 
ilustra mejor con el método de recuperación ARIES, 
descrito en Mohán et al. [1992] y en Mohán [1990b]. 
ARIES y sus variantes se usan en varios productos de 
bases de datos, incluyendo DB2 de IBM y Microsoft 
SQL Server. La recuperación en Oracle se describe en 
Lahiri et al. [2001]. 

Mohán y Levine [1992] y Mohán [1993] proporcio¬ 
nan técnicas de recuperación especiales para estructu¬ 
ras con índices; Mohán y Narang [1994] describen téc¬ 
nicas de recuperación para arquitecturas cliente-servidor, 
mientras que Mohán y Narang [1991] y Mohán y Narang 
[1992] describen técnicas de recuperación para arqui¬ 
tecturas de bases de datos paralelas. 

King et al. [1991] y Polyzois y García-Molina 
[1994] consideran las copias de seguridad remotas 
para recuperación de desastres (pérdida completa de 
un componente del sistema informático a causa de, 
por ejemplo, un incendio, una inundación o un terre¬ 
moto). 

En el Capítulo 24 se encuentran referencias sobre las 
transacciones de larga duración y los aspectos de recu¬ 
peración relacionados. 
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PARTE 


VI 


ARQUITECTURA 
DE LOS SISTEMAS 
DE BASES DE DATOS 


L a arquitectura de los sistemas de bases de datos está enormemente 
influenciada por el sistema informático subyacente en el que se ejecuta 
el sistema de bases de datos. Los sistemas de bases de datos pueden ser 
centralizados, o cliente-servidor, donde una máquina que hace de servidor 
ejecuta trabajos de múltiples máquinas clientes. Los sistemas de bases de datos 
también pueden diseñarse para explotar las arquitecturas paralelas de 
computadoras. Las bases de datos distribuidas abarcan muchas máquinas 
separadas geográficamente. 

El Capítulo 18 comienza tratando las arquitecturas de los sistemas de bases 
de datos que se ejecutan en sistemas servidores, los cuales se utilizan en 
arquitecturas centralizadas y cliente-servidor. En este capítulo se tratan los 
diferentes procesos que juntos implementan la funcionalidad de la base de datos. 
Después, se estudian las arquitecturas paralelas de computadoras y las 
arquitecturas paralelas de bases de datos diseñadas para diferentes tipos de 
computadoras paralelas. Finalmente, el capítulo trata asuntos arquitectónicos 
para la construcción de un sistema distribuido de bases de datos. 

El Capítulo 19 presenta varias cuestiones que surgen en una base de datos 
distribuida, y describe cómo tratar cada cuestión. Estas cuestiones incluyen 
cómo almacenar datos, cómo asegurar la atomicidad de las transacciones que 
se ejecutan en varios emplazamientos, cómo realizar el control de la 
concurrencia y cómo proporcionar alta disponibilidad ante la presencia de fallos. 
En este capítulo también se estudian el procesamiento distribuido de consultas 
y los sistemas de directorio. 

El Capítulo 20 describe cómo varias acciones de una base de datos, en 
particular el procesamiento de consultas, se pueden implementar para explotar 
el procesamiento paralelo. 


CAPÍTULO 



ARQUITECTURAS DE LOS SISTEMAS 
DE BASES DE DATOS 


L a arquitectura de un sistema de bases de datos está influenciada en gran medida por el 
sistema informático subyacente en el que se ejecuta, en particular por aspectos de la arqui¬ 
tectura de la computadora como la conexión en red, el paralelismo y la distribución: 


• La conexión en red de varias computadoras permite que algunas tareas se ejecuten en 
un sistema servidor y que otras se ejecuten en los sistemas clientes. Esta división de tra¬ 
bajo ha conducido al desarrollo de sistemas de bases de datos cliente-servidor. 

• El procesamiento paralelo dentro de una computadora permite acelerar las actividades 
del sistema de base de datos, proporcionando a las transacciones unas respuestas más 
rápidas así como la capacidad de ejecutar más transacciones por segundo. Las consul¬ 
tas pueden procesarse de manera que se explote el paralelismo ofrecido por el sistema 
informático subyacente. La necesidad del procesamiento paralelo de consultas ha con¬ 
ducido al desarrollo de los sistemas de bases de datos paralelos. 

• La distribución de datos a través de las distintas sedes o departamentos de una organiza¬ 
ción permite que estos datos residan donde han sido generados o donde son más necesa¬ 
rios, pero continuar siendo accesibles desde otros lugares o departamentos diferentes. El 
hecho de guardar varias copias de la base de datos en diferentes sitios permite que pue¬ 
dan continuar las operaciones sobre la base de datos aunque algún sitio se vea afectado 
por algún desastre natural como una inundación, un incendio o un terremoto. Se han desa¬ 
rrollado los sistemas distribuidos de bases de datos para manejar datos distribuidos geo¬ 
gráfica o administrativamente a lo largo de múltiples sistemas de bases de datos. 


En este capítulo se estudia la arquitectura de los sistemas de bases de datos comenzando con 
los tradicionales sistemas centralizados y tratando, más adelante, los sistemas de bases de datos 
cliente-servidor, paralelos y distribuidos. 


18.1. ARQUITECTURAS CENTRALIZADAS Y CLIENTE-SERVIDOR 


Los sistemas de bases de datos centralizados son aque¬ 
llos que se ejecutan en un único sistema informático sin 
interaccionar con ninguna otra computadora. Tales sis¬ 
temas comprenden el rango desde los sistemas de bases 
de datos monousuario ejecutándose en computadoras 
personales hasta los sistemas de bases de datos de alto 
rendimiento ejecutándose en grandes sistemas. Por otro 
lado, los sistemas cliente-servidor tienen su funciona¬ 
lidad dividida entre el sistema servidor y múltiples sis¬ 
temas clientes. 

18.1.1. Sistemas centralizados 

Una computadora moderna de propósito general con¬ 
siste en una o unas pocas unidades centrales de proce¬ 
samiento y un número determinado de controladores 
para los dispositivos que se encuentran conectados a 
través de un bus común, el cual proporciona acceso a 
la memoria compartida (Figura 18.1). Las UCP (unida¬ 


des centrales de procesamiento) poseen memorias caché 
locales donde se almacenan copias de ciertas partes de 
la memoria para acelerar el acceso a los datos. Cada 
controlador de dispositivo se encarga de un tipo espe¬ 
cífico de dispositivos (por ejemplo, una unidad de dis¬ 
co, una tarjeta de sonido o un monitor). Las UCP y los 
controladores de dispositivos pueden ejecutarse concu¬ 
rrentemente compitiendo así por el acceso a la memo¬ 
ria. La memoria caché reduce la disputa por el acceso 
a la memoria, ya que la UCP necesita acceder a la 
memoria compartida un número de veces menor. 

Se distinguen dos formas de utilizar las computado¬ 
ras: como sistemas monousuario o multiusuario. En la 
primera categoría están las computadoras personales y 
las estaciones de trabajo. Un sistema monousuario típi¬ 
co es una unidad de sobremesa utilizada por una única 
persona que dispone de una sola UCP, de uno o dos dis¬ 
cos fijos y que trabaja con un sistema operativo que sólo 
permite un único usuario. Por el contrario, un sistema 
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FIGURA 18.1. Un sistema informático centralizado. 


multiusuario típico tiene más discos y más memoria, 
puede disponer de varias UCP y trabaja con un sistema 
operativo multiusuario. Se encarga de dar servicio a un 
gran número de usuarios que están conectados al siste¬ 
ma a través de terminales. 

Normalmente, los sistemas de bases de datos dise¬ 
ñados para funcionar sobre sistemas monousuario no 
suelen proporcionar muchas de las facilidades que ofre¬ 
cen los sistemas multiusuario. En particular no tienen 
control de concurrencia, que no es necesario cuando 
solamente un usuario puede generar modificaciones. 
Las facilidades de recuperación en estos sistemas o no 
existen o son primitivas; por ejemplo, realizar una copia 
de seguridad de la base de datos antes de cualquier modi¬ 
ficación. La mayoría de estos sistemas no admiten SQL 
y proporcionan un lenguaje de consulta muy simple que, 
en algunos casos, es una variante de QBE. En cambio, 
los sistemas de bases de datos diseñados para sistemas 
multiusuario soportan todas las características de las 
transacciones que se han estudiado antes. 

Aunque hoy en día las computadoras de propósito 
general tienen varios procesadores, utilizan paralelis¬ 
mo de grano grueso, disponiendo de unos pocos pro¬ 
cesadores (normalmente dos o cuatro) que comparten 
la misma memoria principal. Las bases de datos que se 
ejecutan en tales máquinas habitualmente no intentan 
dividir una consulta simple entre los distintos proce¬ 
sadores, sino que ejecuta cada consulta en un único pro¬ 
cesador posibilitando la concurrencia de varias con¬ 
sultas. Así, estos sistemas soportan una mayor 
productividad, es decir, permiten ejecutar un mayor 
número de transacciones por segundo, a pesar de que 
cada transacción individualmente no se ejecute más 
rápido. 


Las bases de datos diseñadas para las máquinas mono- 
procesador ya disponen de multitarea permitiendo que 
varios procesos se ejecuten a la vez en el mismo proce¬ 
sador, usando tiempo compartido, mientras que de cara 
al usuario parece que los procesos se están ejecutando 
en paralelo. De esta manera, desde un punto de vista lógi¬ 
co, las máquinas paralelas de grano grueso parecen ser 
idénticas a las máquinas monoprocesador, y pueden adap¬ 
tarse fácilmente los sistemas de bases de datos diseña¬ 
dos para máquinas de tiempo compartido para que pue¬ 
dan ejecutarse sobre máquinas paralelas de grano grueso. 

Por el contrario, las máquinas paralelas de grano 
fino tienen un gran número de procesadores y los sis¬ 
temas de bases de datos que se ejecutan sobre ellas inten¬ 
tan hacer paralelas las tareas simples (consultas, por 
ejemplo) que solicitan los usuarios. En el Apartado 18.3 
se estudia la arquitectura de los sistemas de bases de 
datos paralelos. 

18.1.2. Sistemas cliente-servidor 

Como las computadoras personales son ahora más rápi¬ 
das, más potentes y más baratas, los sistemas se han ido 
distanciando de la arquitectura centralizada. Los termi¬ 
nales conectados a un sistema central han sido suplan¬ 
tados por computadoras personales. De igual forma, la 
interfaz de usuario, que solía estar gestionada directa¬ 
mente por el sistema central, está pasando a ser gestio¬ 
nada, cada vez más, por las computadoras personales. 
Como consecuencia, los sistemas centralizados actúan 
hoy como sistemas servidores que satisfacen las peti¬ 
ciones generadas por los sistemas clientes. En la Ligu- 
ra 18.2 se representa la estructura general de un siste¬ 
ma cliente-servidor. 
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FIGURA 18.2. Estructura general de un sistema cliente-servidor. 


Como se muestra en la Figura 18.3, la funcionali¬ 
dad de una base de datos se puede dividir a grandes ras¬ 
gos en dos partes: la parte visible al usuario y el siste¬ 
ma subyacente. El sistema subyacente gestiona el 
acceso a las estructuras, la evaluación y optimización 
de consultas, el control de concurrencia y la recupera¬ 
ción. La parte visible al usuario de un sistema de base 
de datos está formado por herramientas como formu¬ 
larios, diseñadores de informes y facilidades gráficas 
de interfaz de usuario. La interfaz entre la parte visible 
al usuario y el sistema subyacente puede ser SQL o una 
aplicación. 

Las normas como ODBC y JDBC, que se vieron en 
el Capítulo 4, se desarrollaron para hacer de interfaz 
entre clientes y servidores. Cualquier cliente que utili¬ 
ce interfaces ODBC o JDBC puede conectarse a cual¬ 
quier servidor que proporcione esta interfaz. 

En las primeras generaciones de sistemas de bases 
de datos, la carencia de tales normas hacía que fuera 
necesario que la interfaz visible y el sistema subyacen¬ 
te fueran proporcionados por el mismo distribuidor de 
software. Con el aumento de las interfaces estándares, 
a menudo diferentes distribuidores proporcionan la inter¬ 
faz visible al usuario y el servidor del sistema subya¬ 


cente. Las herramientas de desarrollo de aplicaciones 
se utilizan para construir interfaces de usuario; propor¬ 
cionan herramientas gráficas que se pueden utilizar para 
construir interfaces sin programar. Algunas de las herra¬ 
mientas de desarrollo de aplicaciones más famosas son 
PowerBuilder, Magic y Borland Delphi; Visual Basic 
también se utiliza bastante en el desarrollo de aplica¬ 
ciones. 

Además, ciertas aplicaciones como las hojas de 
cálculo y los paquetes de análisis estadístico utilizan la 
interfaz cliente-servidor directamente para acceder a los 
datos del servidor subyacente. De hecho, proporcionan 
interfaces visibles especiales para diferentes tareas. 

Algunos sistemas de procesamiento de transaccio¬ 
nes proporcionan una interfaz de llamada a procedi¬ 
mientos remotos para transacciones para conectar 
los clientes con el servidor. Estas llamadas aparecen 
para el programador como llamadas normales a pro¬ 
cedimientos, pero todas las llamadas a procedimien¬ 
tos remotos hechas desde un cliente se engloban en 
una única transacción al servidor final. De este modo, 
si la transacción se cancela, el servidor puede desha¬ 
cer los efectos de las llamadas a procedimientos remo¬ 
tos individuales. 


interfaz de 


interfaz de 


diseñador de 


interfaz 

usuario SQL 


formularios 


informes 


gráfica 


parte visible al usuario 


interfaz (SQL + API) 


motor SQL 


sistema subyacente 


FIGURA 18.3. Funcionalidades de la parte visible al usuario y del sistema subyacente. 
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18.2. ARQUITECTURAS DE SISTEMAS SERVIDORES 


Los sistemas servidores pueden dividirse en servidores 
de transacciones y servidores de datos. 

• Los sistemas servidores de transacciones, también 
llamados sistemas servidores de consultas, pro¬ 
porcionan una interfaz a través de la cual los clien¬ 
tes pueden enviar peticiones para realizar una acción 
que el servidor ejecutará y cuyos resultados se devol¬ 
verán al cliente. Normalmente, las máquinas clien¬ 
te envían las transacciones a los sistemas servido¬ 
res, lugar en el que estas transacciones se ejecutan, 
y los resultados se devuelven a los clientes que son 
los encargados de visualizar los datos. Las peticio¬ 
nes se pueden especificar utilizando SQL o median¬ 
te la interfaz de una aplicación especializada. 

• Los sistemas servidores de datos permiten a los 
clientes interaccionar con los servidores realizan¬ 
do peticiones de lectura o modificación de datos en 
unidades tales como archivos o páginas. Por ejem¬ 
plo, los servidores de archivos proporcionan una 
interfaz de sistema de archivos a través de la cual 
los clientes pueden crear, modificar, leer y borrar 
archivos. Los servidores de datos de los sistemas 
de bases de datos ofrecen muchas más funcionali¬ 
dades; soportan unidades de datos de menor tama¬ 
ño que los archivos, como páginas, tupias u obje¬ 
tos. Proporcionan facilidades de indexación de los 
datos, así como facilidades de transacción de modo 
que los datos nunca se quedan en un estado incon¬ 
sistente si falla una máquina cliente o un proceso. 

De éstas, la arquitectura del servidor de transacciones 
es, con mucho, la arquitectura más ampliamente utili¬ 
zada. En los Apartados 18.2.1 y 18.2.2 se desarrollarán 
las arquitecturas de los servidores de transacciones y de 
los servidores de datos. 

18.2.1. Estructura de procesos del servidor de 
transacciones 

Hoy en día, un sistema servidor de transacciones típico 
consiste en múltiples procesos accediendo a los datos 
en una memoria compartida, como en la Figura 18.4. 
Los procesos que forman parte del sistema de bases de 
datos incluyen: 

• Procesos servidor: son procesos que reciben con¬ 
sultas del usuario (transacciones), las ejecutan, y 
devuelven los resultados. Las consultas deben 
enviarse a los procesos servidor desde la interfaz 
de usuario, o desde un proceso de usuario que eje¬ 
cuta SQL incorporado, o a través de JDBC, ODBC 
o protocolos similares. Algunos sistemas de bases 
de datos utilizan un proceso distinto para cada 
sesión de usuario, y algunas utilizan un único pro¬ 


ceso de la base de datos para todas las sesiones del 
usuario, pero con múltiples hebras de forma que se 
pueden ejecutar concurrentemente múltiples con¬ 
sultas. (Una hebra es como un proceso, pero varias 
hebras se ejecutan como parte del mismo proceso, 
y todas las hebras dentro de un proceso se ejecutan 
en el mismo espacio de memoria virtual. Dentro de 
un proceso se pueden ejecutar concurrentemente 
múltiples hebras.) Algunos sistemas de bases de 
datos utilizan una arquitectura híbrida, con proce¬ 
sos múltiples, cada uno de ellos con varias hebras. 

• Proceso gestor de bloqueos: este proceso imple- 
menta una función de gestión de bloqueos que 
incluye concesión de bloqueos, liberación de blo¬ 
queos y detección de interbloqueos. 

• Proceso escritor de bases de datos: hay uno o más 
procesos que vuelcan al disco los bloques de memo¬ 
ria intermedia modificados de forma continua. 

• Proceso escritor del registro: este proceso gene¬ 
ra entradas del registro en el almacenamiento esta¬ 
ble a partir de la memoria intermedia del registro. 
Los procesos servidor simplifican la adición de 
entradas a la memoria intermedia del registro en 
memoria compartida y, si es necesario forzar la 
escritura del registro, le piden al proceso escritor 
del registro que vuelque las entradas del registro. 

• Proceso punto de revisión: este proceso realiza 
periódicamente puntos de revisión. 

• Proceso monitor de proceso: este proceso obser¬ 
va otros procesos y, si cualquiera de ellos falla, rea¬ 
liza acciones de recuperación para el proceso, tales 
como cancelar cualquier transacción que estuviera 
ejecutando el proceso fallido, y reinicia el proceso. 

La memoria compartida contiene todos los datos 
compartidos, como: 

• Grupo de memorias intermedias 

• Tabla de bloqueos 

• Memoria intermedia del registro, que contiene las 
entradas del registro que esperan a ser volcadas en 
el almacenamiento estable 

• Planes de consulta en caché, que se pueden reuti¬ 
lizar si se envía de nuevo la misma consulta 

Todos los procesos de la base de datos pueden acce¬ 
der a los datos de la memoria compartida. Ya que múl¬ 
tiples procesos pueden leer o realizar actualizaciones 
en las estructuras de datos en memoria compartida, 
debe haber un mecanismo que asegure que sólo uno 
de ellos está modificando una estructura de datos en 
un momento dado, y que ningún proceso está leyendo 
una estructura de datos mientras otros la escriben. Tal 
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discos del registro histórico 


discos de datos 


FIGURA 18.4. Estructura de la memoria compartida y de los procesos. 


exclusión mutua se puede implementar por medio de 
funciones del sistema operativo llamadas semáforos. 
Implementaciones alternativas, con menos sobrecar¬ 
gas, utilizan instrucciones atómicas especiales sopor¬ 
tadas por el hardware de la computadora; un tipo de 
instrucción atómica comprueba una posición de la 
memoria y la establece a uno automáticamente. Se pue¬ 
den encontrar más detalles sobre la exclusión mutua 
en cualquier libro de texto de un sistema operativo 
estándar. Los mecanismos de exclusión mutua tam¬ 
bién se utilizan para implementar pestillos. 

Para evitar la sobrecarga del paso de mensajes, en 
muchos sistemas de bases de datos los procesos servi¬ 
dor implementan el bloqueo actualizando directamen¬ 
te la tabla de bloqueos (que está en memoria compar¬ 
tida), en lugar de enviar mensajes de solicitud de 
bloqueo a un proceso administrador de bloqueos. El 


procedimiento de solicitud de bloqueos ejecuta las 
acciones que realizaría el proceso administrador de blo¬ 
queos para procesar una solicitud de bloqueo. Las 
acciones de la solicitud y la liberación de bloqueos son 
como las del Apartado 16.1.4, pero con dos diferencias 
significativas: 

• Dado que varios procesos servidor pueden acce¬ 
der a la memoria compartida, se asegurará la exclu¬ 
sión mutua en la tabla de bloqueos. 

• Si no se puede obtener un bloqueo inmediatamente 
a causa de un conflicto de bloqueos, el código de 
la solicitud de bloqueo sigue observando la tabla 
de bloqueos hasta percatarse de que se ha conce¬ 
dido el bloqueo. El código de liberación de blo¬ 
queo actualiza la tabla de bloqueos para indicar a 
qué proceso se le ha concedido el bloqueo. 
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Para evitar repetidas comprobaciones de la tabla 
de bloqueos, el código de solicitud de bloqueo pue¬ 
de utilizar los semáforos del sistema operativo para 
esperar una notificación de una concesión de blo¬ 
queo. El código de liberación de bloqueo debe uti¬ 
lizar entonces el mecanismo de semáforos para 
notificar a las transacciones que están esperando 
que sus bloqueos hayan sido concedidos. 

Incluso si el sistema gestiona las solicitudes de bloqueo 
por medio de memoria compartida, aún utiliza el pro¬ 
ceso administrador de bloqueos para la detección de 
interbloqueos. 

18.2.2. Servidores de datos 

Los sistemas servidores de datos se utilizan en redes de 
área local en las que se alcanza una alta velocidad de 
conexión entre los clientes y el servidor, las máquinas 
clientes son comparables al servidor en cuanto a poder 
de procesamiento y se ejecutan tareas de cómputo inten¬ 
sivo. En este entorno tiene sentido enviar los datos a las 
máquinas clientes, realizar allí todo el procesamiento 
(que puede durar un tiempo) y después enviar los datos 
de vuelta al servidor. Nótese que esta arquitectura nece¬ 
sita que los clientes posean todas las funcionalidades 
del sistema subyacente. Las arquitecturas de los servi¬ 
dores de datos se han hecho particularmente populares 
en los sistemas de bases de datos orientadas a objetos. 

En esta arquitectura surgen algunos aspectos intere¬ 
santes, ya que el coste en tiempo de comunicación entre 
el cliente y el servidor es alto comparado al de acceso 
a una memoria local (milisegundos frente a menos de 
100 nanosegundos). 

• Envío de páginas o envío de elementos. La uni¬ 
dad de comunicación de datos puede ser de grano 
grueso, como una página, o de grano fino, como 
una tupia (o, en el contexto de los sistemas de bases 
de datos orientados a objetos, un objeto). Se usa¬ 
rá el término elemento para referirse tanto a tupias 
como a objetos. 

Si la unidad de comunicación de datos es un úni¬ 
co elemento, la sobrecarga por la transferencia de 
mensajes es alta comparada con el número de datos 
transmitidos. En vez de hacer esto, cuando se nece¬ 
sita un elemento, cobra sentido la idea de enviar 
junto a aquél otros elementos que probablemente 
vayan a ser utilizados en un futuro próximo. Se 
denomina preextracción a la acción de buscar y 
enviar elementos antes de que sea estrictamente 
necesario. Si varios elementos residen en un pági¬ 
na, el envío de páginas puede considerarse como 
una forma de preextracción, ya que, cuando un pro¬ 
ceso desee acceder a un único elemento de la pági¬ 
na, se enviarán todos los elementos de esa página. 

• Bloqueo. La concesión del bloqueo de los ele¬ 
mentos de datos que el servidor envía a los clien¬ 


tes la realiza habitualmente el propio servidor. Un 
inconveniente del envío de páginas es que los clien¬ 
tes pueden recibir bloqueos de grano grueso: el 
bloqueo de una página bloquea implícitamente a 
todos los elementos que residan en ella. El clien¬ 
te adquiere implícitamente bloqueos sobre todos 
los elementos preextraídos incluso aunque no esté 
accediendo a algunos de ellos. De esta forma, pue¬ 
de detenerse innecesariamente el procesamiento 
de otros clientes que necesiten bloquear esos ele¬ 
mentos. Se han propuesto algunas técnicas para la 
liberación de bloqueos en las que el servidor pue¬ 
de pedir a los clientes que le devuelvan el control 
sobre los bloqueos de los elementos preextraídos. 
Si el cliente no necesita el elemento preextraído 
puede devolver los bloqueos sobre ese elemento 
al servidor para que éstos puedan ser asignados a 
otros clientes. 

• Caché de datos. Los datos que se envían al clien¬ 
te en favor de una transacción se pueden alojar en 
una caché del cliente incluso una vez completada 
la transacción, si dispone de suficiente espacio de 
almacenamiento libre. Las transacciones sucesi¬ 
vas en el mismo cliente pueden hacer uso de los 
datos en caché. Sin embargo, se presenta el pro¬ 
blema de la coherencia de caché: si una transac¬ 
ción encuentra los datos en la caché, debe asegu¬ 
rarse de que esos datos están al día, ya que, después 
de haber sido almacenados en la caché, pueden 
haber sido modificados por otro cliente. Así, debe 
establecerse una comunicación con el servidor para 
comprobar la validez de los datos y poder adqui¬ 
rir un bloqueo sobre ellos. 

• Caché de bloqueos. Los bloqueos también pue¬ 
den ser almacenados en la memoria caché del 
cliente si la utilización de los datos está práctica¬ 
mente dividida entre los clientes, de manera que 
un cliente rara vez necesita datos que están sien¬ 
do utilizados por otros clientes. Supóngase que se 
encuentran en la memoria caché tanto el elemen¬ 
to de datos que se busca como el bloqueo reque¬ 
rido para acceder al mismo. Entonces, el cliente 
puede acceder al elemento de datos sin necesidad 
de comunicar nada al servidor. No obstante, el ser¬ 
vidor debe seguir el rastro de los bloqueos en 
caché; si un cliente solicita un bloqueo al servidor, 
éste debe comunicar a todos los bloqueos sobre 
el elemento de datos que se encuentren en las 
memorias caché de otros clientes. La tarea se vuel¬ 
ve más complicada cuando se tienen en cuenta los 
posibles fallos de la máquina. Esta técnica se dife¬ 
rencia de la liberación de bloqueos en que la caché 
de bloqueo se realiza a través de transacciones; de 
otra forma, las dos técnicas serían similares. 

Las referencias bibliográficas proporcionan más 
información sobre los sistemas cliente-servidor de bases 
de datos. 
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18.3. SISTEMAS PARALELOS 


Los sistemas paralelos mejoran la velocidad de proce¬ 
samiento y de E/S mediante la utilización de UCP y dis¬ 
cos en paralelo. Cada vez son más comunes las máqui¬ 
nas paralelas, lo que hace que cada vez sea más 
importante el estudio de los sistemas paralelos de bases 
de datos. La fuerza que ha impulsado a los sistemas 
paralelos de bases de datos ha sido la demanda de apli¬ 
caciones que han de manejar bases de datos extrema¬ 
damente grandes (del orden de terabytes, esto es, 10 12 
bytes) o que tienen que procesar un número enorme de 
transacciones por segundo (del orden de miles de tran¬ 
sacciones por segundo). Los sistemas de bases de datos 
centralizados o cliente-servidor no son suficientemen¬ 
te potentes para soportar tales aplicaciones. 

En el procesamiento paralelo se realizan muchas ope¬ 
raciones simultáneamente mientras que en el procesa¬ 
miento secuencial, los distintos pasos computacionales 
han de ejecutarse en serie. Una máquina paralela de gra¬ 
no grueso consiste en un pequeño número de potentes 
procesadores; una máquina masivamente paralela o 
de grano fino utiliza miles de procesadores más peque¬ 
ños. Hoy en día, la mayoría de las máquinas de gama 
alta ofrecen un cierto grado de paralelismo de grano 
grueso: son comunes las máquinas con dos o cuatro pro¬ 
cesadores. Las computadoras masivamente paralelas se 
distinguen de las máquinas paralelas de grano grueso 
porque son capaces de soportar un grado de paralelis¬ 
mo mucho mayor. Ya se encuentran en el mercado com¬ 
putadoras paralelas con cientos de UCP y discos. 

Para medir el rendimiento de los sistemas de bases 
de datos existen dos medidas principales: (1) la pro¬ 
ductividad, número de tareas que pueden completarse 
en un intervalo de tiempo determinado, y (2) el tiempo 
de respuesta, cantidad de tiempo que necesita para com¬ 
pletar una única tarea a partir del momento en que se 
envíe. Un sistema que procese un gran número de peque¬ 
ñas transacciones puede mejorar la productividad rea¬ 
lizando muchas transacciones en paralelo. Un sistema 
que procese transacciones largas puede mejorar el tiem¬ 
po de respuesta así como la productividad realizando 
en paralelo las distintas subtareas de cada transacción. 

18.3.1. Ganancia de velocidad y ampliabilidad 

La ganancia de velocidad y la ampliabilidad son dos 
aspectos importantes en el estudio del paralelismo. La 
ganancia de velocidad se refiere a la ejecución en 
menos tiempo de una tarea dada mediante el incremen¬ 
to del grado de paralelismo. La ampliabilidad se refie¬ 
re al manejo de transacciones más largas mediante el 
incremento del grado de paralelismo. 

Considérese un sistema paralelo con un cierto núme¬ 
ro de procesadores y discos que está ejecutando una 
aplicación de base de datos. Supóngase ahora que se 
incrementa el tamaño del sistema añadiéndole más pro¬ 


cesadores, discos y otros componentes. El objetivo es 
realizar el procesamiento de la tarea en un tiempo inver¬ 
samente proporcional al número de procesadores y dis¬ 
cos del sistema. Supóngase que el tiempo de ejecución 
de una tarea en la máquina más grande es T G y que el 
tiempo de ejecución de la misma tarea en la máquina 
más pequeña es T p . La ganancia de velocidad debida al 
paralelismo se define como T P /T c . Se dice que un sis¬ 
tema paralelo tiene una ganancia de velocidad lineal 
si la ganancia de velocidad es N cuando el sistema más 
grande tiene N veces más recursos (UCP, discos, etc.) 
que el sistema más pequeño. Si la ganancia de veloci¬ 
dad es menor que N se dice que el sistema tiene una 
ganancia de velocidad sublineal. En la Figura 18.5 se 
muestra la ganancia de velocidad lineal y sublineal. 

La ampliabilidad está relacionada con la capacidad 
para procesar tareas más largas en el mismo tiempo 
mediante el incremento de los recursos del sistema. Sea 
Q una tarea y sea Q N una tarea N veces más grande que 
Q. Supóngase que T P es el tiempo de ejecución de la 
tarea Q en una máquina dada M P y que T c es el tiempo 
de ejecución de la tarea Q N en una máquina paralela M a , 
la cual es N veces más grande que M p . La ampliabili- 
dad se define como T P /T 0 . Se dice que el sistema para¬ 
lelo M c tiene una ampliabilidad lineal sobre la tarea Q 
si T p = T g . Si T g > T p se dice que el sistema tiene una 
ampliabilidad sublineal. En la Figura 18.6 se muestra 
la ampliabilidad lineal y sublineal (donde los recursos 
aumentan proporcionalmente al tamaño del problema). 
La manera de medir el tamaño de las tareas da lugar a 
dos tipos de ampliabilidad relevantes en los sistemas 
paralelos de bases de datos: 

• En la ampliabilidad por lotes aumenta el tama¬ 
ño de la base de datos, y las tareas son trabajos más 
largos cuyos tiempos de ejecución dependen del 
tamaño de la base de datos. Recorrer una relación 
cuyo tamaño es proporcional al tamaño de la base 
de datos sería un ejemplo de tales tareas. Así, la 



FIGURA 18.5. Ganancia de velocidad respecto al incremento 
de los recursos. 
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medida del tamaño del problema es el tamaño de 
la base de datos. La ampliabilidad por lotes tam¬ 
bién se utiliza en aplicaciones científicas tales como 
la ejecución de una consulta con una resolución N 
veces mayor o la realización de una simulación N 
veces más larga. 

• En la ampliabilidad de transacciones aumenta la 
velocidad con la que se envían las transacciones a 
la base de datos y el tamaño de la base de datos 
crece proporcionalmente a la tasa de transaccio¬ 
nes. Este tipo de ampliabilidad es el relevante en 
los sistemas de procesamiento de transacciones en 
los que las transacciones son modificaciones peque¬ 
ñas -por ejemplo, un abono o retirada de fondos 
de una cuenta -y cuantas más cuentas se creen, 
más crece la tasa de transacciones. Este procesa¬ 
miento de transacciones se adapta especialmente 
bien a la ejecución en paralelo, ya que las tran¬ 
sacciones pueden ejecutarse concurrente e inde¬ 
pendientemente en procesadores distintos y cada 
transacción dura más o menos el mismo tiempo, 
aunque crezca la base de datos. 

La ampliabilidad es normalmente el factor más 
importante para medir la eficiencia de un sistema para¬ 
lelo de bases de datos. El objetivo del paralelismo en 
los sistemas de bases de datos suele ser asegurar que la 
ejecución del sistema continuará realizándose a una 
velocidad aceptable incluso en el caso de que aumente 
el tamaño de la base de datos o el número de transac¬ 
ciones. El incremento de la capacidad del sistema 
mediante el incremento del paralelismo proporciona a 
una empresa un modo de crecimiento más suave que el 
de reemplazar un sistema centralizado por una máqui¬ 
na más rápida (suponiendo incluso que esta máquina 
existiera). Sin embargo, cuando se utiliza la ampliabi¬ 
lidad debe atenderse también a los valores del rendi¬ 
miento absoluto; una máquina con un ampliabilidad 
lineal puede tener un rendimiento más bajo que otra con 
ampliabilidad sublineal simplemente porque la última 
sea mucho más rápida que la primera. 



tamaño del problema 


FIGURA 18.6. Ampliabilidad respecto al crecimiento del 
tamaño del problema. 


Existen algunos factores que trabajan en contra de 
la eficiencia del paralelismo y pueden atenuar tanto la 
ganancia de velocidad como la ampliabilidad. 

• Costes de inicio. El inicio de un único proceso lle¬ 
va asociado un coste. En una operación paralela 
compuesta por miles de procesos el tiempo de ini¬ 
cio puede llegar a ser mucho mayor que el tiempo 
real de procesamiento, lo que influye negativa¬ 
mente en la ganancia de velocidad. 

• Interferencia. Como los procesos que se ejecutan 
en un sistema paralelo acceden con frecuencia a 
recursos compartidos, pueden sufrir un cierto retar¬ 
do como consecuencia de la interferencia de cada 
nuevo proceso en la competencia con los procesos 
existentes por el acceso a los recursos más comu¬ 
nes, como el bus del sistema, los discos comparti¬ 
dos o incluso los bloqueos. Este fenómeno afecta 
tanto a la ganancia de velocidad como a la amplia¬ 
bilidad. 

• Sesgo. Al dividir cada tarea en un cierto número de 
pasos paralelos se reduce el tamaño del paso medio. 
Es más, el tiempo de servicio de la tarea completa 
vendrá determinado por el tiempo de servicio del 
paso más lento. Normalmente es difícil dividir una 
tarea en partes exactamente iguales, entonces se dice 
que la forma de distribución de los tamaños es ses¬ 
eada. Por ejemplo, si se divide una tarea de tamaño 
100 en 10 partes y la división está sesgada, puede 
haber algunas tareas de tamaño menor que 10 y otras 
de tamaño superior a 10; si el tamaño de una tarea 
fuera 20, la ganancia de velocidad que se obtendría 
al ejecutar las tareas en paralelo sólo valdría 5 en vez 
de lo que cabría esperarse, 10. 

18.3.2. Redes de interconexión 

Los sistemas paralelos están constituidos por un con¬ 
junto de componentes (procesadores, memoria y dis¬ 
cos) que pueden comunicarse entre sí a través de una 
red de interconexión. La Figura 18.7 muestra tres tipos 
de redes de interconexión utilizados frecuentemente: 

• Bus. Todos los componentes del sistema pueden 
enviar o recibir datos de un único bus de comuni¬ 
caciones. Este tipo de interconexión se muestra en 
la Figura 18.7a. El bus puede ser una red Ethernet 
o una interconexión paralela. Las arquitecturas de 
bus trabajan bien para un pequeño número de pro¬ 
cesadores. Sin embargo, como el bus sólo puede 
gestionar la comunicación de un único componente 
en cada momento, las arquitecturas de bus son 
menos apropiadas según aumenta el paralelismo. 

• Malla. Los componentes se organizan como los 
nodos de una retícula de modo que cada compo¬ 
nente está conectado con todos los nodos adya¬ 
centes. En una malla bidimensional cada nodo está 
conectado con cuatro nodos adyacentes, mientras 
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(a) Bus (b) Malla 

FIGURA 18.7. Redes de interconexión. 



(c) Hipercubo 


111 


110 


que en una malla tridimensional cada nodo está 
conectado con seis nodos adyacentes. La Figura 
18.7b muestra una malla bidimensional. Los nodos 
entre los que no existe una conexión directa pue¬ 
den comunicarse mediante el envío de mensajes a 
través de una secuencia de nodos intermedios que 
sí dispongan de conexión directa. A medida que 
aumenta el número de componentes también 
aumenta el número de enlaces de comunicación, 
por lo que la capacidad de comunicación, de una 
malla es mejor cuanto mayor es el paralelismo. 

• Hipercubo. Se asigna a cada componente un 
número binario de modo que dos componentes tie¬ 
nen una conexión directa si sus correspondientes 
representaciones binarias difieren en un solo bit. 
Así, cada uno de los n componentes está conecta¬ 
do con otros log(ri) componentes. La Figura 18.7c 
muestra un hipercubo con 8 vértices. Puede demos¬ 
trarse que, en un hipercubo, un mensaje de un com¬ 
ponente puede llegar a cualquier otro componen¬ 
te de la red de interconexión atravesando a lo sumo 


log(n ) enlaces. Por el contrario, en una malla un 
componente puede estar a 2(Vñ - 1) enlaces de 
otros componentes (o a \fn enlaces de distancia si 
la malla de interconexión conecta entre sí los bor¬ 
des opuestos). De esta manera, el retardo de la 
comunicación en un hipercubo es significativa¬ 
mente menor que en una malla. 

18.3.3. Arquitecturas paralelas de bases de datos 

Existen varios modelos de arquitecturas para las máqui¬ 
nas paralelas. En la Figura 18.8 se muestran algunos de 
los más importantes (en la figura, M quiere decir memo¬ 
ria, P procesador y los discos se dibujan como cilindros): 

• Memoria compartida. Todos los procesadores 
comparten una memoria común (Figura 18.8a). 

• Disco compartido. Todos los procesadores com¬ 
parten un conjunto de discos común (Figura 18.8b). 
Algunas veces los sistemas de disco compartido 
se denominan agrupaciones. 




(a) Memoria compartida (b) D¡sco com p ar t¡do 



(c) Sin compartimiento (d) Jerárquico 


FIGURA 18.8. Arquitecturas paralelas de bases de datos. 
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• Sin compartimiento. Los procesadores no com¬ 
parten ni memoria ni disco (Figura 18.8c). 

• Jerárquico. Este modelo es un híbrido de las arqui¬ 
tecturas anteriores (Figura 18.8d). 

En los Apartados 18.3.3.1 hasta el 18.3.3.4 se aborda¬ 
rá cada uno de estos modelos. 

Las técnicas utilizadas para acelerar el procesamiento 
de transacciones en sistemas servidores de datos, como 
la caché de datos y bloqueos y la liberación de bloqueos, 
tratadas en el Apartado 18.2.2, también se pueden uti¬ 
lizar en bases de datos paralelas de discos compartidos 
además de en bases de datos paralelas sin comparti¬ 
miento. De hecho, son muy importantes para el proce¬ 
samiento eficiente de transacciones en tales sistemas. 

18.3.3.1. Memoria compartida 

En una arquitectura de memoria compartida los proce¬ 
sadores y los discos tienen acceso a una memoria común, 
normalmente a través de un bus o de una red de interco¬ 
nexión. El beneficio de la memoria compartida es la extre¬ 
mada eficiencia en cuanto a la comunicación entre pro¬ 
cesadores; cualquier procesador puede acceder a los datos 
de la memoria compartida sin necesidad de la interven¬ 
ción del software. Un procesador puede enviar mensajes 
a otros procesadores utilizando escrituras en la memoria 
de modo que la velocidad de envío es mucho mayor (nor¬ 
malmente es inferior a un microsegundo) que la que se 
alcanza con un mecanismo de comunicación. El incon¬ 
veniente de las máquinas con memoria compartida es que 
la arquitectura no puede ir más allá de 32 o 64 procesa¬ 
dores porque el bus o la red de interconexión se conver¬ 
tirían en un cuello de botella (ya que está compartido por 
todos los procesadores). Llega un momento en el que no 
sirve de nada añadir más procesadores, ya que éstos 
emplean la mayoría de su tiempo esperando su tumo para 
utilizar el bus y así poder acceder a la memoria. 

Las arquitecturas de memoria compartida suelen dotar 
a cada procesador de una memoria caché muy grande 
para evitar las referencias a la memoria compartida siem¬ 
pre que sea posible. No obstante, en la caché no podrán 
estar todos los datos y no podrá evitarse el acceso a la 
memoria compartida. Además, las cachés necesitan man¬ 
tener la coherencia; esto es, si un procesador realiza una 
escritura en una posición de memoria, los datos de dicha 
posición de memoria se deberían actualizar en o elimi¬ 
nar de cualquier procesador donde estuvieran los datos 
en caché. El mantenimiento de la coherencia de la caché 
aumenta la sobrecarga cuando aumenta el número de 
procesadores. Por estas razones las máquinas con memo¬ 
ria compartida no pueden extenderse llegado un punto; 
las máquinas actuales con memoria compartida no pue¬ 
den soportar más de 64 procesadores. 

18.3.3.2. Disco compartido 

En el modelo de disco compartido todos los procesa¬ 
dores pueden acceder directamente a todos los discos a 


través de una red de interconexión, pero los procesa¬ 
dores tienen memorias privadas. Las arquitecturas de 
disco compartido ofrecen dos ventajas respecto de las 
de memoria compartida. Primero, el bus de la memoria 
deja de ser un cuello de botella, ya que cada procesa¬ 
dor dispone de memoria propia. Segundo, esta arqui¬ 
tectura ofrece una forma barata para proporcionar una 
cierta tolerancia ante fallos: si falla un procesador (o 
su memoria) los demás procesadores pueden hacerse 
cargo de sus tareas, ya que la base de datos reside en los 
discos, a los cuales tienen acceso todos los procesado¬ 
res. Como se describía en el Capítulo 11, utilizando una 
arquitectura RAID también puede conseguirse que el 
subsistema de discos sea tolerante ante fallos por sí mis¬ 
mo. La arquitectura de disco compartido tiene acepta¬ 
ción en bastantes aplicaciones. 

El problema principal de los sistemas de discos com¬ 
partidos es, de nuevo, la ampliabilidad. Aunque el bus de 
la memoria no es cuello de botella muy grande, la inter¬ 
conexión con el subsistema de discos es ahora el nuevo 
cuello de botella; esto es especialmente grave en situa¬ 
ciones en las que la base de datos realiza un gran número 
de accesos a los discos. Los sistemas de discos compar¬ 
tidos pueden soportar un mayor número de procesado¬ 
res en comparación con los sistemas de memoria com¬ 
partida, pero la comunicación entre los procesadores es 
más lenta (hasta unos pocos milisegundos si se carece de 
un hardware de propósito especial para comunicaciones), 
ya que se realiza a través de una red de interconexión. 

Las agrupaciones DEC con Rdb constituyen uno de 
los primeros usuarios de la arquitectura de bases de datos 
de disco compartido (Rdb ahora es propiedad de Ora¬ 
cle y se denomina Oracle Rdb. Digital Equipment Cor¬ 
poration (DEC) es ahora propiedad de Compaq). 

18.3.3.3. Sin compartimiento 

En un sistema sin compartimiento cada nodo de la 
máquina consta de un procesador, memoria y uno o más 
discos. Los procesadores de un nodo pueden comuni¬ 
carse con un procesador de otro nodo utilizando una red 
de interconexión de alta velocidad. Un nodo funciona 
como el servidor de los datos almacenados en los dis¬ 
cos que posee. El modelo sin compartimiento salva el 
inconveniente de requerir que todas las operaciones de 
E/S vayan a través de una única red de interconexión, 
ya que las referencias a los discos locales son servidas 
por los discos locales de cada procesador; solamente 
van por la red las peticiones, los accesos a discos remo¬ 
tos y las relaciones de resultados. Es más, habitualmente 
las redes de interconexión para los sistemas sin com¬ 
partimiento se diseñan para ser ampliables por lo que 
su capacidad de transmisión crece a medida que se aña¬ 
den nuevos nodos. Como consecuencia, las arquitectu¬ 
ras sin compartimiento son más ampliables y pueden 
soportar con facilidad un gran número de procesadores. 
El principal inconveniente de los sistemas sin compar¬ 
timiento es el coste de comunicación y de acceso a dis¬ 
cos remotos, coste que es mayor que el que se produce 
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en las arquitecturas de memoria o disco compartido, ya 
que el envío de datos provoca la intervención del soft¬ 
ware en ambos extremos. 

La máquina de base de datos Teradata fue uno de los 
primeros sistemas comerciales que utilizaron la arqui¬ 
tectura sin compartimiento de bases de datos. También 
se construyeron sobre arquitecturas sin compartimien¬ 
to los prototipos de investigación Grace y Gamma. 

18.3.3.4. Jerárquica 

La arquitectura jerárquica combina las característi¬ 
cas de las arquitecturas de memoria compartida, de dis¬ 
co compartido y sin compartimiento. A alto nivel el sis¬ 
tema está formado por nodos que están conectados 
mediante una red de interconexión y que no comparten 
ni memoria ni discos. Así, el nivel más alto es una arqui¬ 
tectura sin compartimiento. Cada nodo del sistema 
podría ser en realidad un sistema de memoria compar¬ 
tida con algunos procesadores. Alternativamente, cada 
nodo podría ser un sistema de disco compartido y cada 
uno de estos sistemas de disco compartido podría ser a 
su vez un sistema de memoria compartida. De esta 
manera, un sistema podría construirse como una jerar¬ 


quía con una arquitectura de memoria compartida con 
pocos procesadores en la base, en lo más alto una arqui¬ 
tectura sin compartimiento y quizá una arquitectura de 
disco compartido en el medio. En la Figura 18.8d se 
muestra una arquitectura jerárquica con nodos de memo¬ 
ria compartida conectados entre sí con una arquitectu¬ 
ra sin compartimiento. Hoy en día los sistemas parale¬ 
los comerciales de bases de datos pueden ejecutarse 
sobre varias de estas arquitecturas. 

Las arquitecturas de memoria virtual distribuida, 
en las que hay una única memoria compartida desde el 
punto de vista lógico pero hay varios sistemas de memo¬ 
ria disjuntos desde el punto de vista físico, han surgido 
tras varios intentos por reducir la complejidad de pro¬ 
gramación de los sistemas jerárquicos; se obtiene una 
única vista del área de memoria virtual de estas memo¬ 
rias disjuntas mediante un hardware de asignación de 
memoria virtual en conjunción con un software extra. 
Dado que las velocidades de acceso son diferentes, 
dependiendo de si la página está disponible localmen¬ 
te o no, esta arquitectura también se denomina arqui¬ 
tectura de memoria no uniforme (NUMA, Nonuni- 
form Memory Architecture). 


18.4. SISTEMAS DISTRIBUIDOS 


En un sistema distribuido de bases de datos se alma¬ 
cena la base de datos en varias computadoras. Varios 
medios de comunicación, como las redes de alta velo¬ 
cidad o las líneas telefónicas, son los que pueden poner 
en contacto las distintas computadoras de un sistema 
distribuido. No comparten ni memoria ni discos. Las 
computadoras de un sistema distribuido pueden variar 
en tamaño y función pudiendo abarcar desde las esta¬ 
ciones de trabajo a los grandes sistemas. 

Dependiendo del contexto en el que se mencionen 
existen diferentes nombres para referirse a las compu¬ 
tadoras que forman parte de un sistema distribuido, tales 
como sitios o nodos. Para enfatizar la distribución físi¬ 
ca de estos sistemas se usa principalmente el término 
sitio. En la Figura 18.9 se muestra la estructura general 
de un sistema distribuido. 

Las principales diferencias entre las bases de datos 
paralelas sin compartimientos y las bases de datos dis¬ 
tribuidas son que las bases de datos distribuidas nor¬ 
malmente se encuentran en varios lugares geográficos 
distintos, se administran de forma separada y poseen una 
interconexión más lenta. Otra gran diferencia es que en 
un sistema distribuido se dan dos tipos de transacciones, 
las locales y las globales. Una transacción local es aque¬ 
lla que accede a los datos del único sitio en el cual se ini¬ 
ció la transacción. Por otra parte, una transacción glo¬ 
bal es aquella que, o bien accede a los datos situados en 
un sitio diferente de aquel en el que se inició la transac¬ 
ción, o bien accede a datos de varios sitios distintos. 


Hay varias razones para construir sistemas distri¬ 
buidos de bases de datos, incluyendo el compartimien¬ 
to de los datos, la autonomía y la disponibilidad. 

• Datos compartidos. La principal ventaja de cons¬ 
truir un sistema distribuido de bases de datos es 
poder disponer de un entorno donde los usuarios 
puedan acceder desde una única ubicación a los 
datos que residen en otras ubicaciones. Por ejem¬ 
plo, en un sistema de banca distribuida, donde cada 
sucursal almacena datos relacionados con dicha 
sucursal, es posible que un usuario de una de las 
sucursales acceda a los datos de otra sucursal. Sin 
esta capacidad, un usuario que quisiera transferir 
fondos de una sucursal a otra tendría que recurrir 
a algún mecanismo externo que pudiera enlazar 
los sistemas existentes. 

• Autonomía. La principal ventaja de compartir 
datos por medio de distribución de datos es que 
cada ubicación es capaz de mantener un grado de 
control sobre los datos que se almacenan local¬ 
mente. En un sistema centralizado, el administra¬ 
dor de bases de datos de la ubicación central con¬ 
trola la base de datos. En un sistema distribuido, 
existe un administrador de bases de datos global 
responsable de todo el sistema. Una parte de estas 
responsabilidades se delegan al administrador de 
bases de datos local de cada sitio. Dependiendo 
del diseño del sistema distribuido de bases de datos, 
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Sitio A Sitio C 



Sitio B 


FIGURA 18.9. Un sistema distribuido. 


cada administrador puede tener un grado diferen¬ 
te de autonomía local. La posibilidad de autono¬ 
mía local es a menudo una de las grandes venta¬ 
jas de las bases de datos distribuidas. 

• Disponibilidad. Si un sitio de un sistema distribui¬ 
do falla, los sitios restantes pueden seguir trabajan¬ 
do. En particular, si los elementos de datos están 
replicados en varios sitios, una transacción que nece¬ 
site un elemento de datos en particular puede encon¬ 
trarlo en varios sitios. De este modo, el fallo de un 
sitio no implica necesariamente la caída del sistema. 

El sistema puede detectar el fallo de un sitio, y 
pueden ser necesarias acciones apropiadas para 
recuperarse del fallo. El sistema no debe seguir 
utilizando los servicios del sitio que falló. Final¬ 
mente, cuando el sitio que falló se recupera o se 
repara, debe haber mecanismos disponibles para 
integrarlo sin problemas de nuevo en el sistema. 

Aunque la recuperación ante un fallo es más 
compleja en los sistemas distribuidos que en los 
sistemas centralizados, la capacidad que tienen 
muchos sistemas de continuar trabajando a pesar 
del fallo en uno de los sitios produce una mayor 
disponibilidad. La disponibilidad es crucial para 
los sistemas de bases de datos que se utilizan en 
aplicaciones de tiempo real. Que, por ejemplo, una 
línea aérea pierda el acceso a los datos puede pro¬ 
vocar la pérdida de potenciales compradores de 
billetes en favor de la competencia. 

18.4.1. Un ejemplo de una base de datos 
distribuida 

Considérese un sistema bancario compuesto por cuatro 
sucursales situadas en cuatro ciudades diferentes. Cada 


sucursal posee su propia computadora con una base de 
datos que alberga todas las cuentas abiertas en dicha 
sucursal. Así, cada una de estas instalaciones se consi¬ 
dera un sitio. También hay un único sitio que mantiene 
la información relativa a todas las sucursales del ban¬ 
co. Cada sucursal dispone (entre otras) de una relación 
cuenta(Esquema-cuentd), donde 

Esquema-cuenta - ( número-cuenta, 
nombre-sucursal, saldo) 

El sitio que contiene información acerca de las cuatro 
sucursales mantiene la relación sucursal(Esquema- 
sucursal), donde 

Esquema-sucursal - ( nombre-sucursal, 
ciudad-sucursal, activos ) 

Existen otras relaciones en los distintos sitios que serán 
ignoradas para los propósitos del ejemplo. 

Para ilustrar la diferencia entre los dos tipos de tran¬ 
sacciones considérese la transacción que suma 50 € a 
la cuenta C-177 situada en la sucursal de Cercedilla. La 
transacción se considera local si ésta comenzó en la 
sucursal de Cercedilla; en otro caso, se considera glo¬ 
bal. Una transacción que transfiere 50 € desde la cuen¬ 
ta C-177 a la cuenta C-305, que se encuentra en la sucur¬ 
sal de Guadarrama, es una transacción global, ya que 
como resultado de su ejecución se accede a datos de dos 
sitios diferentes. 

En un sistema distribuido de bases de datos ideal, los 
sitios deberían compartir un esquema global común 
(aunque algunas relaciones se puedan almacenar sólo 
en algunos sitios), todos los sitios deberían ejecutar el 
mismo software de gestión de bases de datos distribui¬ 
das, y los sitios deberían conocer la existencia de los 
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demás. Si una base de datos distribuida se construye 
partiendo de cero, realmente debería ser posible lograr 
los objetivos anteriores. Sin embargo, en la realidad, 
una base de datos distribuida se tiene que construir enla¬ 
zando múltiples sistemas de bases de datos que ya exis¬ 
ten, cada uno con su propio esquema y posiblemente 
ejecutando diferente software de gestión de bases de 
datos. A veces, tales sistemas reciben el nombre de sis¬ 
temas de bases de datos múltiples o sistemas distri¬ 
buidos y heterogéneos de bases de datos. En el Apar¬ 
tado 19.8 se discuten dichos sistemas y se muestra cómo 
conseguir un cierto grado de control global a pesar de 
la heterogeneidad de los sistemas que lo componen. 

18.4.2. Aspectos de la implementación 

La atomicidad de las transacciones es un aspecto impor¬ 
tante de la construcción de un sistema distribuido de 
bases de datos. Si una transacción se ejecuta a lo largo 
de dos sitios, a menos que los diseñadores del sistema 
sean cuidadosos, puede comprometerse en un sitio y 
cancelarse en otro, lo que conduciría a un estado de 
inconsistencia. Los protocolos de compromiso de tran¬ 
sacciones aseguran que tales situaciones no se produz¬ 
can. El protocolo de compromiso de dos fases (C2F) es 
el más utilizado de estos protocolos. 

La idea básica del C2F es que cada sitio ejecuta la 
transacción justo hasta antes del compromiso, y enton¬ 
ces deja la decisión del compromiso a un único sitio 
coordinador; se dice que en ese punto la transacción 
está en estado preparada en el sitio. El coordinador 
decide comprometer la transacción sólo si la transac¬ 
ción alcanza el estado preparada en cada sitio donde se 
ejecutó; en otro caso (por ejemplo, si la transacción se 
canceló en algún sitio), el coordinador decide cancelar 
la transacción. Todos los sitios donde la transacción se 
ejecutó deben acatar la decisión del coordinador. Si un 
sitio falla cuando una transacción se encuentra en esta¬ 
do preparada, cuando el sitio se recupere del fallo debe¬ 
ría estar en posición de comprometer o cancelar la tran¬ 
sacción dependiendo de la decisión del coordinador. El 
protocolo C2F se describe en detalle en el Apartado 
19.4.1. 

El control de concurrencia es otra característica de 
una base de datos distribuida. Como una transacción 
puede acceder a elementos de datos de varios sitios, los 
administradores de transacciones de varios sitios pue¬ 
den necesitar coordinarse para implementar el control 
de la concurrencia. Si se utiliza bloqueo (como casi 
siempre sucede en la práctica), el bloqueo se puede rea¬ 
lizar de forma local en los sitios que contienen los ele¬ 
mentos de datos accedidos, pero también existe posi¬ 
bilidad de un interbloqueo que involucre a transacciones 
originadas en múltiples sitios. Por lo tanto, es necesa¬ 
rio llevar la detección de interbloqueos a lo largo de 
múltiples sitios. Los fallos son más comunes en los sis¬ 
temas distribuidos, dado que no sólo las computadoras 
pueden fallar, sino que también pueden fallar los enla¬ 


ces de comunicaciones. La réplica de los elementos de 
datos, que es la clave para el funcionamiento conti¬ 
nuado de las bases de datos distribuidas cuando ocu¬ 
rren fallos, complica aún más el control de la concu¬ 
rrencia. El Apartado 19.5 proporciona más detalles 
sobre el control de la concurrencia en bases de datos 
distribuidas. 

Los modelos estándar de transacciones, basados en 
múltiples acciones llevadas a cabo por una única uni¬ 
dad de programa, son a menudo inapropiadas para rea¬ 
lizar tareas que cruzan los límites de las bases de datos 
que no pueden o no cooperarán para implementar pro¬ 
tocolos como el C2F. Para estas tareas se utilizan gene¬ 
ralmente técnicas alternativas, basadas en mensajería 
persistente para las comunicaciones. 

Cuando las tareas a realizar son complejas, involu¬ 
crando múltiples bases de datos y múltiples interaccio¬ 
nes con humanos, la coordinación de las tareas y ase¬ 
gurar las propiedades de las transacciones para las tareas 
se vuelve más complicado. Los sistemas de gestión de 
flujos de trabajo son sistemas diseñados para ayudar en 
la realización de dichas tareas. El Apartado 19.4.3 des¬ 
cribe la mensajería persistente, mientras que el Aparta¬ 
do 24.2 describe los sistemas de gestión de flujos de tra¬ 
bajo. 

En caso de que una empresa tenga que escoger entre 
una arquitectura distribuida y una arquitectura centra¬ 
lizada para implementar una aplicación, el arquitecto 
del sistema debe sopesar las ventajas frente a las des¬ 
ventajas de la distribución de datos. Ya se han exami¬ 
nado las ventajas de utilizar bases de datos distribui¬ 
das. El principal inconveniente de los sistemas 
distribuidos de bases de datos es la complejidad añadi¬ 
da que es necesaria para garantizar la coordinación apro¬ 
piada entre los sitios. Esta creciente complejidad tiene 
varias facetas: 

• Coste de desarrollo del software. La implemen¬ 
tación de un sistema distribuido de bases de datos 
es más difícil y, por lo tanto, más costoso. 

• Mayor probabilidad de errores. Como los sitios 
que constituyen el sistema distribuido operan en 
paralelo es más difícil asegurarse de la corrección 
de los algoritmos, del funcionamiento especial 
durante los fallos de parte del sistema así como de 
la recuperación. Son probables errores extrema¬ 
damente sutiles. 

• Mayor sobrecarga de procesamiento. El inter¬ 
cambio de mensajes y el cómputo adicional nece¬ 
sario para conseguir la coordinación entre los dis¬ 
tintos sitios constituyen una forma de sobrecarga 
que no surge en los sistemas centralizados. 

Existen varios enfoques acerca del diseño de las 
bases de datos distribuidas que abarcan desde los dise¬ 
ños completamente distribuidos hasta los que inclu¬ 
yen un alto grado de centralización. Se estudiarán en 
el Capítulo 19. 
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18.5. TIPOS DE REDES 


Las bases de datos distribuidas y los sistemas cliente- 
servidor se construyen en tomo a las redes de comuni¬ 
cación. Existen básicamente dos clases de redes: las 
redes de área local y las redes de área amplia. La dife¬ 
rencia principal entre ambas es la forma en que están 
distribuidas geográficamente. Las redes de área local 
están compuestas por procesadores distribuidos en áreas 
geográficas pequeñas tales como un único edificio o 
varios edificios adyacentes. Por su parte, las redes de 
área amplia se componen de un número determinado de 
procesadores autónomos que están distribuidos a lo lar¬ 
go de una extensa área geográfica (como puede ser Espa¬ 
ña o el mundo entero). Estas diferencias implican impor¬ 
tantes variaciones en la velocidad y en la fiabilidad de 
la red de comunicación y quedan reflejadas en el dise¬ 
ño del sistema operativo distribuido. 

18.5.1. Redes de área local 

Las redes de área local (LANs, Local Area Networks) 
(Figura 18.10) surgen a principios de los 70 como una 
forma de comunicación y de compartimiento de datos 
entre varias computadoras. La gente se dio cuenta de 
que en muchas empresas era más económico tener 
muchas computadoras pequeñas, cada una de ellas con 
sus propias aplicaciones, que un enorme y único siste¬ 
ma. La conexión de estas pequeñas computadoras for¬ 
mando una red parece un paso natural porque, proba¬ 
blemente, cada pequeña computadora necesite acceder 
a un conjunto complementario de dispositivos periféri¬ 


cos (como discos e impresoras) y porque en una empre¬ 
sa suele ser necesaria el compartimiento de algunos 
datos. 

Las LAN se utilizan generalmente en un entorno de 
oficina. Todos los puestos de estos sistemas están pró¬ 
ximos entre sí por lo que los enlaces de comunicación 
suelen poseer una mayor velocidad y una tasa de erro¬ 
res más baja que la que se da en las redes de área 
amplia. Los enlaces más comunes en una red de área 
local son el par trenzado, el cable coaxial, la fibra ópti¬ 
ca y, cada vez más, las conexiones inalámbricas. La 
velocidad de comunicación varía entre unos pocos 
megabits por segundo (en las redes de área local ina¬ 
lámbricas), a un gigabit por segundo para Gigabit Ether¬ 
net. La Ethernet estándar funciona a 10 megabits por 
segundo, mientras que Fast Ethernet llega a 100 mega¬ 
bits por segundo. 

Una red de área de almacenamiento (SAN, Sto- 
rage-Area NetWork) es un tipo especial de red de área 
local de alta velocidad destinada a conectar numerosos 
bancos de dispositivos de almacenamiento (discos) a 
las computadoras que utilizan los datos. Así, las redes 
de área de almacenamiento ayudan a construir sistemas 
de discos compartidos a gran escala. El motivo para uti¬ 
lizar redes de área de almacenamiento para conectar 
múltiples computadoras a grandes bancos de dispositi¬ 
vos de almacenamiento es esencialmente el mismo que 
para las bases de datos de disco compartido, a saber: 

• Escalabilidad añadiendo más computadoras. 


Estación de trabajo Impresora 


Servidor de UCP 


Procesadores 


Procesadores 



FIGURA 18.10. Red de área local. 
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• Alta disponibilidad, ya que los datos están todavía 
accesibles incluso si una computadora falla. 

Las organizaciones RAID se utilizan en dispositivos de 
almacenamiento para asegurar la alta disponibilidad de 
los datos, permitiendo continuar al procesamiento inclu¬ 
so si discos individuales fallan. Las redes de área de 
almacenamiento se construyen normalmente con redun¬ 
dancia, como múltiples caminos entre nodos, así si un 
componente como un enlace o una conexión a la red 
falla, la red continúa funcionando. 

18.5.2. Redes de área amplia 

Las redes de área amplia (WAN, Wide Area Net¬ 
works) surgen a finales de los 60 principalmente como 
un proyecto de investigación académica para propor¬ 
cionar una comunicación eficiente entre varios lugares 
permitiendo que una gran comunidad de usuarios pudie¬ 
ra compartir hardware y software de una manera con¬ 
veniente y económica. A principios de los años 60 se 
desarrollaron sistemas que permitían que terminales 
remotos se conectaran a una computadora central a tra¬ 
vés de la línea telefónica, pero no eran verdaderas 
WANs. Arpanet fue la primera WAN que se diseñó y se 
desarrolló. El trabajo en Arpanet comenzó en 1968. 
Arpanet ha crecido de tal forma que ha pasado de ser 
una red experimental de cuatro puestos a una red de 
redes extendida por todo el mundo, Internet, abarcan¬ 
do a cientos de millones de sistemas de computación. 
Los enlaces típicos de Internet son las líneas de fibra 
óptica y, a veces, los canales vía satélite. Las transfe¬ 
rencias de datos para los enlaces de área amplia varían 
normalmente entre los pocos megabits por segundo y 


los cientos de gigabits por segundo. El último enlace, 
hasta el puesto del usuario, se basa a menudo en la tec¬ 
nología de bucle de suscripto)' digital (DSL, digital subs- 
criber loop) (que soporta unos pocos megabits por 
segundo), o módem de cable (que soporta 10 megabits 
por segundo) o conexiones de módem telefónico sobre 
líneas telefónicas (que soportan hasta 56 kilobits por 
segundo). 

Pueden distinguirse dos tipos de WANs: 

• En las WAN de conexión discontinua, como las 
basadas en conexiones por radio, las computado¬ 
ras están conectadas a la red sólo durante interva¬ 
los del tiempo. 

• En las WAN de conexión continua, como Inter¬ 
net, las computadoras están conectadas a la red 
continuamente. 

Las redes que no están continuamente conectadas no 
suelen permitir las transacciones entre distintos sitios, 
pero pueden almacenar copias locales de los datos remo¬ 
tos y actualizarlas periódicamente (por ejemplo, todas 
las noches). Para las aplicaciones en las que la consis¬ 
tencia no es un factor crítico, como ocurre en el com¬ 
partimiento de documentos, los sistemas de software de 
grupo como Lotus Notes permiten realizar localmente 
las actualizaciones de los datos remotos y propagar más 
tarde dichas actualizaciones al sitio remoto. Debe detec¬ 
tarse y resolverse el riesgo potencial de conflicto entre 
varias actualizaciones realizadas en sitios diferentes. 
Más adelante, en el Apartado 23.5.4, se describe un 
mecanismo para detectar actualizaciones conflictivas; 
el mecanismo de resolución de actualizaciones conflic¬ 
tivas es, sin embargo, dependiente de la aplicación. 


18.6. RESUMEN 


• Los sistemas centralizados de bases de datos se eje¬ 
cutan completamente en una única computadora. Con 
el crecimiento de las computadoras personales y las 
redes de área local, se ha ido desplazando hacia el 
lado del cliente la funcionalidad de la parte visible al 
usuario de la base de datos de modo que los sistemas 
servidores provean la funcionalidad del sistema sub¬ 
yacente. Los protocolos de interfaz cliente-servidor 
han ayudado al crecimiento de los sistemas de bases 
de datos cliente-servidor. 

• Los servidores pueden ser servidores de transaccio¬ 
nes o servidores de datos, aunque el uso de los servi¬ 
dores de transacciones excede ampliamente el uso de 
los servidores de datos para proporcionar servicios de 
bases de datos. 

- Los servidores de transacciones tienen múltiples 
procesos, ejecutándose posiblemente en múltiples 
procesadores. Dado que estos procesos tienen acce¬ 


so a los datos comunes, como la memoria inter¬ 
media de la base de datos, los sistemas almacenan 
dichos datos en memoria compartida. Además de 
los procesos que gestionan consultas, hay procesos 
del sistema que realizan tareas como la gestión de 
los bloqueos y del registro y los puntos de revisión. 
- Los sistemas servidores de datos suministran datos 
sin formato a los clientes. Tales sistemas se esfuer¬ 
zan en minimizar la comunicación entre clientes y 
servidores usando caché de datos y de bloqueos en 
los clientes. Los sistemas paralelos de bases de 
datos utilizan optimizaciones similares. 

• Los sistemas paralelos de bases de datos consisten en 
varios procesadores y varios discos conectados a tra¬ 
vés de una red de interconexión de alta velocidad. La 
ganancia de velocidad mide cuánto puede incremen¬ 
tarse la velocidad de procesamiento al incrementarse 
el paralelismo dada una transacción. La ampliabili- 
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dad mide lo bien que se gestiona un mayor número 
de transacciones cuando se incrementa el paralelis¬ 
mo. La interferencia, el sesgo y los costes de inicio 
actúan como barreras para obtener la ganancia de velo¬ 
cidad y la ampliabilidad ideales. 

• Las arquitecturas paralelas de bases de datos pueden 
clasificarse en arquitecturas de memoria compartida, 
de disco compartido, sin compartimiento o jerárqui¬ 
cas. Estas arquitecturas tienen distintos compromisos 
entre la ampliabilidad y la velocidad de comunicación. 

• Una base de datos distribuida es un conjunto de bases 
de datos parcialmente independientes que (idealmente) 
comparten un esquema común y coordinan el proce¬ 
samiento de transacciones que acceden a datos remo¬ 
tos. Los procesadores se comunican entre sí a través 


de una red de comunicación que gestiona el encami¬ 
namiento y las estrategias de conexión. 

• Hay dos tipos principales de redes de comunicación: 
las redes de área local y las de área amplia. Las redes 
de área local conectan nodos que están distribuidos 
sobre áreas geográficas pequeñas tales como un úni¬ 
co edificio o varios edificios adyacentes. Las redes de 
área amplia conectan nodos a lo largo de una exten¬ 
sa área geográfica. Hoy en día, la red de área amplia 
más extensa que se utiliza es Internet. 

Las redes de área de almacenamiento son un tipo 
especial de redes de área local diseñadas para propor¬ 
cionar interconexión rápida entre grandes bancos de 
dispositivos de almacenamiento y múltiples computa¬ 
doras. 


TÉRMINOS DE REPASO 


Ampliabilidad 

- Ampliabilidad de transacciones 

- Ampliabilidad lineal 

- Ampliabilidad por lotes 

- Ampliabilidad sublineal 
Arquitectura de memoria no uniforme 
Arquitecturas paralelas de bases de datos 

- Disco compartido (agrupaciones) 

- Jerárquico 

- Memoria compartida 

- Sin compartimiento 
Bases de datos distribuidas 

- Autonomía local 

- Sitios (nodos) 

- Transacción global 

- Transacción local 
Costes de inicio 

Estructura de proceso de la base de datos 
Exclusión mutua 
Ganancia de velocidad 

- Ganancia de velocidad lineal 

- Ganancia de velocidad sublineal 
Hebra 

Interferencia 

Memoria virtual distribuida 
Paralelismo de grano fino 
Paralelismo de grano grueso 
Procesos servidor 

- Proceso administrador de bloqueos 

- Proceso escritor de bases de datos 


- Proceso escritor del registro 

- Proceso monitor de procesos 

- Proceso punto de revisión 

• Productividad 

• Redes de interconexión 

- Bus 

- Hipercubo 

- Malla 

• Sesgo 

• Servidor de consultas 

• Servidor de datos 

- Caché de bloqueos 

- Caché de datos 

- Coherencia de caché 

- Comunicar 

- Liberación de bloqueos 

- Preextracción 

• Servidor de transacciones 

• Sistema con múltiples bases de datos 

• Sistemas centralizados 

• Sistemas cliente-servidor 

• Sistemas distribuidos 

• Sistemas paralelos 

• Sistemas servidores 

• Tiempo de respuesta 

• Tipos de redes 

- Redes de área de almacenamiento (SAN) 

- Redes de área amplia (WAN) 

- Redes de área local (LAN) 

• Tolerancia ante fallos 
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CAPÍTULO 18 ARQUITECTURAS DE LOS SISTEMAS DE BASES DE DATOS 


EJERCICIOS 


18.1. ¿Por qué es relativamente fácil trasladar una base de 
datos desde una máquina con un único procesador a 
otra con varios procesadores si no es necesario hacer 
paralelas las consultas individuales? 

18.2. Las arquitecturas servidoras de transacciones son 
populares entre las bases de datos relaciónales clien¬ 
te-servidor, en las que las transacciones son cortas. 
Por el contrario, las arquitecturas servidoras de datos 
son populares entre los sistemas cliente-servidor de 
bases de datos orientadas a objetos, donde las tran¬ 
sacciones son relativamente largas. Dense dos razo¬ 
nes por las que los servidores de datos puedan ser 
populares entre las bases de datos orientadas a obje¬ 
tos y no los sean entre las bases de datos relaciónales. 

18.3. En lugar de almacenar estructuras compartidas en 
memoria compartida, una arquitectura alternativa 
podría ser almacenarlas en la memoria local de un pro¬ 
ceso especial, y acceder a los datos compartidos 
mediante comunicación entre procesos con el proce¬ 
so. ¿Cuál sería la desventaja de dicha arquitectura? 

18.4. La máquina que hace de servidor en los sistemas clien¬ 
te-servidor típicos es mucho más potente que los clien¬ 
tes, es decir, su procesador es más rápido, puede tener 
varios procesadores, tiene más memoria y tiene dis¬ 
cos de mayor capacidad. En vez de esto, considérese 
el caso en el que los clientes y el servidor tuvieran 
exactamente la misma potencia. ¿Tendría sentido cons¬ 
truir un sistema cliente-servidor en ese caso? ¿Por 
qué? ¿Qué caso se ajustaría mejor a una arquitectura 
servidora de datos? 

18.5. Considérese un sistema de base de datos orientada a 
objetos sobre una arquitectura cliente-servidor en la 
que el servidor actúa como servidor de datos. 

a. ¿Cuál es el efecto de la velocidad de interconexión 
entre el cliente y el servidor en los casos de envío 
de páginas y de objetos? 

b. Si se utiliza envío de páginas, la caché de datos en 
el cliente puede organizarse como una caché de 
objetos o una caché de páginas. La caché de pági¬ 
nas almacena los datos en unidades de páginas 
mientras que la caché de objetos almacena los datos 
en unidades de objetos. Supóngase que los objetos 
son más pequeños que una página. Descríbase una 


ventaja de la caché de objetos frente a la caché de 
páginas. 

18.6. ¿Qué es la liberación de bloqueos y bajo qué condi¬ 
ciones es necesaria? ¿Por qué no es necesario si la uni¬ 
dad de envío de datos es un elemento? 

18.7. Suponga que se encuentra a cargo de las operaciones 
de la base de datos de una empresa cuyo trabajo prin¬ 
cipal es el de procesar transacciones. Suponga que la 
empresa crece rápidamente cada año y que el sistema 
informático actual se ha quedado pequeño. Cuando 
escoja una nueva computadora paralela, ¿qué factor 
será más importante: la ganancia de velocidad, la 
ampliabilidad por lotes o la ampliabilidad de tran¬ 
sacciones? ¿Por qué? 

18.8. Supóngase una transacción escrita en C con código 
SQL incorporado que ocupa el 80 por ciento del tiem¬ 
po en ejecutar el código SQL y sólo el 20 por ciento 
restante en el código C. ¿Qué ganancia de velocidad 
puede esperarse si sólo se hace paralelo el código 
SQL? Justifiqúese la respuesta. 

18.9. En un sistema de procesamiento de transacciones, 
¿cuáles son los factores que trabajan en contra de la 
ampliabilidad lineal? ¿Cuál de esos factores es pro¬ 
bablemente el más importante en cada una de estas 
arquitecturas: memoria compartida, disco comparti¬ 
do y sin compartimiento? 

18.10. Considérese un banco que dispone de un conjunto de 
sitios en los que se ejecuta un sistema de base de datos. 
Supóngase que la transferencia electrónica de dinero 
entre ellos es el único modo de interacción de las bases 
de datos. ¿Puede un sistema tal ser calificado como 
distribuido? ¿Por qué? 

18.11. Considérese una red basada en líneas de acceso tele¬ 
fónico en la que los sitios se comunican periódica¬ 
mente, por ejemplo, todas las noches. Estas redes sue¬ 
len tener un servidor y varios clientes. Los sitios que 
actúan como clientes están conectados sólo con el ser¬ 
vidor e intercambian los datos con el resto de clien¬ 
tes almacenándolos en el servidor y recuperando los 
almacenados por otros clientes en el servidor. ¿Cuál 
es la ventaja de tal arquitectura frente a una en la que 
un sitio pueda intercambiar datos con otro mediante 
acceso telefónico directo? 


NOTAS BIBLIOGRÁFICAS 


Los libros de Patterson y Hennessy [1995] y Stone 
[1993] proporcionan una buena introducción al área de 
la arquitectura de computadoras. 

Gray y Reuter [1993] dan una descripción en su libro 
del procesamiento de transacciones incluyendo la arqui¬ 
tectura de cliente-servidor y los sistemas distribuidos. 
Geiger [1995] y Signore et al. [1995] describen la nor¬ 


ma ODBC para la conectividad cliente-servidor. En North 
[1995] pueden encontrarse descripciones de varias herra¬ 
mientas para el acceso cliente-servidor a bases de datos. 

Carey et al. [1991] y Franklin et al. [1993] descri¬ 
ben técnicas de caché de datos para los sistemas de bases 
de datos cliente-servidor. Biliris y Orenstein [1994] tra¬ 
tan los sistemas de gestión de almacenamiento de obje- 
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tos incluyendo aspectos relacionados con los sistemas 
cliente-servidor. En Franklin et al. [1992] y Mohán y 
Narang [1994] pueden encontrarse algunas técnicas para 
la recuperación en sistemas cliente-servidor. 

De Witt y Gray [1992] describen los sistemas para¬ 
lelos de bases de datos incluyendo sus propias arqui¬ 
tecturas y medidas de rendimiento. Duncan [1990] intro¬ 
duce una vista de las arquitecturas paralelas de 
computadoras. Dubois y Thakkar [1992] es una colec¬ 
ción de artículos sobre las arquitecturas ampliables de 
memoria compartida. 


Ozsu y Valduriez [1999], Bell y Grimson [1992] y 
Ceri y Pelagatti [1984] proporcionan textos sobre los 
sistemas distribuidos de bases de datos. Se pueden 
encontrar más referencias sobre los sistemas de bases 
de datos paralelos y distribuidos en las notas bibliográ¬ 
ficas de los Capítulos 20 y 19, respectivamente. 

Comer y Droms [1999] y Thomas [1996] describen 
las redes de computadoras e Internet. Tanenbaum [1996] 
y Halsall [1992] proporcionan revisiones generales de 
las redes de computadoras. Prycker [1993] examina las 
Redes MTA y los conmutadores. 
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CAPÍTULO 



BASES DE DATOS DISTRIBUIDAS 


A diferencia de los sistemas paralelos, en los que los procesadores se hallan estrecha¬ 
mente acoplados y constituyen un único sistema de bases de datos, los sistemas dis¬ 
tribuidos de bases de datos consisten en sitios débilmente acoplados que no compar¬ 
ten ningún componente físico. Además, puede que los sistemas de bases de datos que se ejecutan 
en cada sitio tengan un grado sustancial de independencia mutua. La estructura básica de los 
sistemas distribuidos se discutió en el Capítulo 18. 

Cada sitio puede participar en la ejecución de transacciones que tienen acceso a los datos de 
uno o varios de los sitios. La diferencia principal entre los sistemas de bases de datos centrali¬ 
zados y los distribuidos es que, en los primeros, los datos residen en una única ubicación, mien¬ 
tras que en los segundos los datos residen en varias ubicaciones. La distribución de los datos 
es causa de muchas dificultades en el procesamiento de las transacciones y de las consultas. En 
este capítulo se abordarán esas dificultades. 

Se comienza por clasificar las bases de datos distribuidas en homogéneas y heterogéneas en 
el Apartado 19.1. Luego se aborda el problema del almacenamiento de los datos en las bases 
de datos distribuidas en el Apartado 19.2. En el Apartado 19.3 se esboza un modelo de proce¬ 
samiento de las transacciones en bases de datos distribuidas. En el Apartado 19.4 se describe 
el modo de implementar transacciones atómicas en bases de datos distribuidas mediante pro¬ 
tocolos de compromiso especiales. En el Apartado 19.5 se describe el control de la concurren¬ 
cia en las bases de datos distribuidas. En el Apartado 19.6 se esboza el modo de proporcionar 
una elevada disponibilidad en bases de datos distribuidas aprovechando las réplicas, de modo 
que el sistema pueda continuar procesando las transacciones aunque se produzca un fallo. El 
procesamiento de las consultas en las bases de datos distribuidas se aborda en el Apartado 19.7. 
En el Apartado 19.8 se esbozan aspectos del manejo de bases de datos heterogéneas. En el Apar¬ 
tado 19.9 se describen los sistemas de directorio, que pueden considerarse una forma especia¬ 
lizada de bases de datos distribuidas. 


19.1. BASES DE DATOS HOMOGÉNEAS Y HETEROGÉNEAS 


En las bases de datos distribuidas homogéneas todos 
los sitios tienen idéntico software de sistemas gestores 
de bases de datos, son conscientes de la existencia de 
los demás sitios y acuerdan cooperar en el procesamiento 
de las solicitudes de los usuarios. En estos sistemas los 
sitios locales renuncian a una parte de su autonomía en 
cuanto a su derecho a modificar los esquemas o el soft¬ 
ware del sistema gestor de bases de datos. Ese softwa¬ 
re también debe cooperar con los demás sitios en el inter¬ 
cambio de la información sobre las transacciones para 
hacer posible el procesamiento de las transacciones entre 
varios sitios. 

A diferencia de lo anterior, en las bases de datos 
distribuidas heterogéneas sitios diferentes puede que 
utilicen esquemas diferentes y diferente software de 
gestión de sistemas de bases de datos. Puede que unos 


sitios no sean conscientes de la existencia de los demás 
y puede que sólo proporcionen facilidades limitadas 
para la cooperación en el procesamiento de las tran¬ 
sacciones. Las diferencias en los esquemas suelen 
constituir un problema importante para el procesa¬ 
miento de las consultas, mientras que la divergencia 
del software supone un inconveniente para el proce¬ 
samiento de transacciones que tengan acceso a varios 
sitios. 

Este capítulo se centrará en las bases de datos dis¬ 
tribuidas homogéneas. No obstante, en el Apartado 19.8 
se discutirán brevemente los aspectos del procesamiento 
de las consultas en los sistemas de bases de datos dis¬ 
tribuidas heterogéneas. Los aspectos del procesamien¬ 
to de las transacciones en dichos sistemas se tratan más 
adelante, en el Apartado 24.6. 
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19.2. ALMACENAMIENTO DISTRIBUIDO DE DATOS 


Considérese una relación r que hay que almacenar en 
la base de datos. Hay dos enfoques del almacenamien¬ 
to de esta relación en la base de datos distribuida: 

• Réplica. El sistema conserva réplicas (copias) 
idénticas de la relación y guarda cada réplica en 
un sitio diferente. La alternativa a las réplicas es 
almacenar sólo una copia de la relación r. 

• Fragmentación. El sistema divide la relación en 
varios fragmentos y guarda cada fragmento en un 
sitio diferente. 

La fragmentación y la réplica pueden combinarse: 
Las relaciones pueden dividirse en varios fragmentos y 
puede haber varias réplicas de cada fragmento. En los 
subapartados siguientes se profundizará en cada una de 
estas técnicas. 

19.2.1. Réplica de datos 

Si la relación r se replica, se guarda una copia de dicha 
relación en dos o más sitios. En el caso más extremo se 
tiene una réplica completa, en la que se guarda una 
copia en cada sitio del sistema. 

Hay varias ventajas y desventajas en las réplicas. 

• Disponibilidad. Si alguno de los sitios que con¬ 
tiene la relación r falla, la relación puede hallarse 
en otro sitio distinto. Por tanto, el sistema puede 
seguir procesando las consultas que impliquen a 
r, pese al fallo del sitio. 

• Paralelismo Incrementado. En caso de que la 
mayoría de los accesos a la relación r sólo resul¬ 
ten en la lectura de la relación, varios sitios pue¬ 
den procesar en paralelo las lecturas que impliquen 
a r. Cuantas más réplicas de r haya, mayor será la 
posibilidad de que los datos necesarios se hallen 
en el sitio en que se ejecuta la transacción. Por tan¬ 
to, la réplica de los datos minimiza el movimien¬ 
to de los datos entre los sitios. 

• Sobrecarga incrementada durante la actualiza¬ 
ción. El sistema debe asegurar que todas las répli¬ 
cas de la relación r sean consistentes; en caso con¬ 
trario pueden producirse cómputos erróneos. Por 
eso, siempre que se actualiza r, hay que propagar 
la actualización a todos los sitios que contienen 
réplicas. El resultado es una sobrecarga incremen¬ 
tada. Por ejemplo, en un sistema bancario, en el 
que se replica en varios sitios la información de las 
cuentas, es necesario asegurarse de que el saldo de 
cada cuenta concuerde en todos los sitios. 

En general, la réplica mejora el rendimiento de las 
operaciones leer y aumenta la disponibilidad de los 


datos para las transacciones sólo de lectura. No obs¬ 
tante, las transacciones de actualización suponen una 
mayor sobrecarga. El control de las actualizaciones de 
actualización realizadas por varias transacciones en 
los datos replicados resulta más complicado que en 
los sistemas centralizados, que se vieron en el Capí¬ 
tulo 16. Se puede simplificar la gestión de las répli¬ 
cas de la relación r escogiendo una de ellas como copia 
principal de r. Por ejemplo, en un sistema bancario, 
las cuentas pueden asociarse con el sitio en que se abrie¬ 
ron. De manera parecida, en un sistema de reserva de 
billetes de avión, los vuelos pueden asociarse con el 
sitio en que se origina el vuelo. Se examinará el esque¬ 
ma de copias principales y otras opciones del control 
de la concurrencia distribuida en el Apartado 19.5. 

19.2.2. Fragmentación de los datos 

Si la relación r se fragmenta, r se divide en varios frag¬ 
mentos r j, r 2 ,, r n . Estos fragmentos contienen sufi¬ 
ciente información como para permitir la reconstrucción 
de la relación original r. Hay dos esquemas diferentes de 
fragmentación de las relaciones: fragmentación horizon¬ 
tal y fragmentación vertical. La fragmentación horizon¬ 
tal divide la relación asignando cada tupia de r en uno o 
más fragmentos. La fragmentación vertical divide la rela¬ 
ción descomponiendo el esquema R de la relación r. 

Estos enfoques se ilustrarán fragmentando la rela¬ 
ción cuenta, con el esquema 

esquema-cuenta = ( número-cuenta, 
nombre-sucursal, saldo) 

En la fragmentación horizontal la relación r se divi¬ 
de en varios subconjuntos, r x , r 2 ,.... r n . Cada tupia de 
la relación r debe pertenecer como mínimo a uno de los 
fragmentos, de modo que se pueda reconstruir la rela¬ 
ción original, si fuera necesario. 

A modo de ejemplo, la relación cuenta puede dividir¬ 
se en varios fragmentos, cada uno de los cuales consiste 
en tupias de cuentas que pertenecen a una sucursal con¬ 
creta. Si el sistema bancario sólo tiene dos sucursales (Gua¬ 
darrama y Cercedilla) habrá dos fragmentos diferentes: 

Cuenta j — Onombre-sucursal = «Guadarrama» (.cuenta) 
cuenta 2 & nombre-sucursal = «Cercedilla» (CUCUlO ) 

La fragmentación horizontal suele utilizarse para 
conservar las tupias en los sitios en que más se utilizan, 
para minimizar la transferencia de datos. 

En general, los fragmentos horizontales pueden defi¬ 
nirse como una selección de la relación global r. Es decir, 
se utiliza un predicado P¡ para construir fragmentos r¡\ 
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Se reconstruye la relación r tomando la unión de 
todos los fragmentos; es decir, 

r = r 1 Ur 2 U"-Ur a 

En el ejemplo los fragmentos son disjuntos. Al cam¬ 
biar los predicados de selección empleados para crear 
los fragmentos se puede hacer que una tupia concreta 
de r aparezca en más de uno de los fragmentos r¡. 

En su forma más sencilla la fragmentación vertical 
es igual que la descomposición (véase el Capítulo 7). 
La fragmentación vertical de r(R) implica la defini¬ 
ción de varios subconjuntos de atributos R lr R 2 ,. . ,,R n 
del esquema R de modo que 

R=R l UR 2 U---UR n 
Cada fragmento r¡ de r se define mediante 
r¡ = H A > ( (r) 

La fragmentación debe hacerse de modo que se pueda 
reconstruir la relación r a partir de los fragmentos toman¬ 
do la reunión natural 

r = r 1 X r 2 X r 3 X • • • XI r n 

Una manera de asegurar que la relación r pueda 
reconstruirse es incluir los atributos de la clave princi¬ 
pal de R en cada uno de los fragmentos R¡. De manera 
más general, se puede utilizar cualquier superclave. Sue¬ 
le resultar conveniente añadir un atributo especial, deno¬ 
minado id-tupla, al esquema/?. El valor id-tupla de una 
tupia es un valor único que distingue cada tupia de todas 
las demás. El atributo id-tupla, por tanto, sirve como 
clave candidata para el esquema aumentado y se inclu¬ 
ye en cada uno de los fragmentos R¡. La dirección físi¬ 
ca o lógica de la tupia puede utilizarse como id-tupla, 
dado que cada tupia tiene una dirección única. 

Para ilustrar la fragmentación vertical considérese una 
base de datos universitaria con una relación info-em- 
pleado que almacena, para cada empleado, id-empleado, 
nombre, puesto y salario. Por motivos de preservación 
de la intimidad puede que esta relación se fragmente en 
una relación empleado-infoprivada que contenga id- 
empleado y salario, y en otra relación empleado-info- 
pública que contenga los atributos id-empleado, nom¬ 
bre y puesto. Puede que las dos relaciones se almacenen 
en sitios diferentes, nuevamente, por motivos de segu¬ 
ridad. 

Se pueden aplicar los dos tipos de fragmentación 
a un solo esquema; por ejemplo, los fragmentos obte¬ 
nidos de la fragmentación horizontal de una relación 
pueden dividirse nuevamente de manera vertical. Los 
fragmentos también pueden replicarse. En general, 
los fragmentos pueden replicarse, las réplicas de los 
fragmentos pueden fragmentarse más, etcétera, etcé¬ 
tera. 


19.2.3. Transparencia 

No se debe exigir a los usuarios de los sistemas distri¬ 
buidos de bases de datos que conozcan la ubicación físi¬ 
ca de los datos ni el modo en que se puede tener acce¬ 
so a ellos en un sitio local concreto. Esta característica, 
denominada transparencia de los datos, puede adop¬ 
tar varias formas: 

• Transparencia de la fragmentación. No se exi¬ 
ge a los usuarios que conozcan el modo en que se 
ha fragmentado la relación. 

• Transparencia de la réplica. Los usuarios ven 
cada objeto de datos como lógicamente único. Pue¬ 
de que el sistema distribuido replique los objetos 
para incrementar el rendimiento del sistema o la 
disponibilidad de los datos. Los usuarios no deben 
preocuparse por los objetos que se hayan replica¬ 
do ni por la ubicación de esas réplicas. 

• Transparencia de la ubicación. No se exige a los 
usuarios que conozcan la ubicación física de los 
datos. El sistema distribuido de bases de datos debe 
poder hallar los datos siempre que la transacción 
del usuario facilite el identificador de los datos. 

Los elementos de datos (como las relaciones, los 
fragmentos y las réplicas) deben tener nombres únicos. 
Esta propiedad es fácil de asegurar en una base de datos 
centralizada. En las bases de datos distribuidas, sin 
embargo, hay que tener cuidado para asegurarse de que 
dos sitios no utilicen el mismo nombre para elementos 
de datos diferentes. 

Una solución a este problema es exigir que todos los 
nombres se registren en un servidor de nombres cen¬ 
tral. El servidor de nombres ayuda a asegurar que el mis¬ 
mo nombre no se utilice para elementos de datos dife¬ 
rentes. También se puede utilizar el servidor de nombres 
para ubicar un elemento de datos, dado el nombre del ele¬ 
mento. Este enfoque, sin embargo, presenta dos incon¬ 
venientes principales. En primer lugar, puede que el ser¬ 
vidor de nombres se transforme en un cuello de botella 
para el rendimiento cuando los elementos de datos se ubi¬ 
can por sus nombres, lo que da lugar a un bajo rendi¬ 
miento. En segundo lugar, si el servidor de nombres que¬ 
da fuera de servicio, puede que no sea posible que siga 
funcionando ningún otro sitio del sistema distribuido. 

Un enfoque alternativo más utilizado exige que cada 
sitio anteponga su propio identificador de sitio a cualquier 
nombre que genere. Este enfoque asegura que dos sitios 
no generen nunca el mismo nombre (dado que cada sitio 
tiene un identificador único). Además, no se necesita nin¬ 
gún control centralizado. Esta solución, no obstante, no 
logra conseguir la transparencia de la ubicación, dado que 
se adjuntan a los nombres los identificadores de los sitios. 
Así, se puede hacer referencia a la relación cuenta como 
sitioYl.cuenta, o cuenta@sitio\l, en lugar de meramen¬ 
te cuenta. Muchos sistemas de bases de datos utilizan la 
dirección de internet de los sitios para identificarlos. 
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Para superar este problema el sistema de bases de 
datos puede crear un conjunto de nombres alternati¬ 
vos o alias para los elementos de datos. Así, los usua¬ 
rios se pueden referir a los artículos de datos median¬ 
te nombres sencillos que el sistema traduce en los 
nombres completos. La asignación de los alias a los 
nombres reales puede almacenarse en cada sitio. Con 
los alias el usuario puede ignorar la ubicación física 
de los elementos de datos. Además, el usuario no se 
verá afectado si el administrador de la base de datos 


decide trasladar un elemento de datos de un sitio a 
otro. 

Los usuarios no deben tener que hacer referencia a 
una réplica concreta de un elemento de datos. En vez 
de eso, el sistema debe determinar la réplica a la que 
hay que hacer referencia en las solicitudes leer, y actua¬ 
lizar todas las réplicas en las solicitudes escribir. Se pue¬ 
de asegurar que lo haga manteniendo una tabla de catá¬ 
logo, que el sistema utiliza para determinar todas las 
réplicas del elemento de datos. 


19.3. TRANSACCIONES DISTRIBUIDAS 


El acceso a los diferentes elementos de datos en los sis¬ 
temas distribuidos suele realizarse mediante transac¬ 
ciones, que deben preservar las propiedades ACID 
(Apartado 15.1). Hay dos tipos de transacciones que se 
deben considerar. Las transacciones locales son las que 
tienen acceso a los datos y los actualizan sólo en una 
base de datos local; las transacciones globales son las 
que tienen acceso a datos y los actualizan en varias bases 
de datos locales. Se pueden asegurar las propiedades 
ACID de las transacciones locales como se describe en 
los capítulos 15, 16 y 17. Sin embargo, para las tran¬ 
sacciones globales, esta tarea resulta mucho más com¬ 
plicada, dado que puede que participen en la ejecución 
varios sitios. El fallo de alguno de estos sitios, o el de 
un enlace de comunicaciones que conecte esos sitios, 
puede dar lugar a cálculos erróneos. 

En este apartado se estudia la estmctura del sistema 
de las bases de datos distribuidas y sus posibles modos 
de fallo. Con base en el modelo presentado en este apar¬ 
tado, en el Apartado 19.4 se estudian los protocolos para 
asegurar el compromiso atómico de las transacciones 
globales, y en el Apartado 19.5 se estudian los protoco¬ 
los para el control de la concurrencia en las bases de 
datos distribuidas. En el Apartado 19.6 se estudia el modo 
en que pueden seguir funcionando las bases de datos dis¬ 
tribuidas incluso en presencia de varios tipos de fallo. 

19.3.1. Estructura del sistema 

Cada sitio tiene su propio gestor local de transacciones, 
cuya función es asegurar las propiedades ACID de las 
transacciones que se ejecuten en ese sitio. Los diferen¬ 
tes gestores de transacciones colaboran para ejecutar las 
transacciones globales. Para comprender el modo en 
que se pueden implementar estos gestores, considérese 
un modelo abstracto de sistema de transacciones, en el 
que cada sitio contenga dos subsistemas: 

• El gestor de transacciones administra la ejecu¬ 
ción de las transacciones (o subtransacciones) que 
tienen acceso a los datos almacenados en un sitio 
local. Téngase en cuenta que cada una de esas tran¬ 


sacciones puede ser una transacción local (es decir, 
una transacción que se ejecuta sólo en ese sitio) o 
parte de una transacción global (es decir, una tran¬ 
sacción que se ejecuta en varios sitios). 

• El coordinador de transacciones coordina la eje¬ 
cución de las diferentes transacciones (tanto loca¬ 
les como globales) iniciadas en ese sitio. 

La arquitectura global del sistema aparece en la Figu¬ 
ra 19.1. 

La estructura de los gestores de transacciones es pare¬ 
cida en muchos aspectos a la de los sistemas centrali¬ 
zados. Cada gestor de transacciones es responsable de 

• Mantenimiento de un registro histórico con fines 
de recuperación 

• Participación en un esquema adecuado de control 
de la concurrencia para coordinar la ejecución con¬ 
currente de las transacciones que se ejecuten en 
ese sitio 

Como se verá, hay que modificar tanto el esquema 
de recuperación como el de concurrencia para adaptar¬ 
los a la distribución de las transacciones. 

El subsistema del coordinador de transacciones no 
se necesita en los entornos centralizados, dado que las 
transacciones sólo tienen acceso a los datos en un sitio. 
Los coordinadores de transacciones, como su propio 
nombre implica, son responsables de la coordinación 
de la ejecución de todas las transacciones iniciadas en 
ese sitio. En cada una de esas transacciones el coordi¬ 
nador es responsable de 

• Inicio de la ejecución de la transacción 

• División de la transacción en varias subtransac¬ 
ciones y distribución de esas subtransacciones a 
los sitios correspondientes para su ejecución 

• Coordinación de la terminación de la transacción, 
que puede hacer que la transacción se comprome¬ 
ta en todos los sitios o que se aborte en todos los 
sitios 
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FIGURA 19.1. 
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19.3.2. Modos de fallo del sistema 

Los sistemas distribuidos pueden sufrir los mismos tipos 
de fallos que los sistemas centralizados (por ejemplo, 
errores de software, errores de hardware y fallos de dis¬ 
cos). No obstante, hay más tipos de fallos con los que 
hay que tratar en los entornos distribuidos. Los tipos 
básicos de fallos son 

• Fallo de un sitio 

• Pérdida de mensajes 

• Fallo de un enlace de comunicaciones 

• División de la red 

La pérdida o deterioro de los mensajes siempre cons¬ 
tituye una posibilidad en los sistemas distribuidos. El sis¬ 
tema utiliza protocolos de control de las transmisiones, 


como TCP/1P, para tratar esos errores. Se puede encontrar 
información sobre esos protocolos en los libros de texto 
estándar sobre redes (véanse las notas bibliográficas). 

No obstante, si dos sitios A y B no se hallan conec¬ 
tados de manera directa, los mensajes de uno a otro 
deben encaminarse mediante una serie de enlaces de 
comunicaciones. Si falla un enlace de comunicaciones 
los mensajes que se deberían haber transmitido por el 
enlace deben reencaminarse. En algunos casos resulta 
posible hallar otra ruta por la red de modo que los men¬ 
sajes puedan alcanzar su destino. En otros casos el fallo 
puede hacer que no halla conexión entre algunos pares 
de sitios. Un sistema está dividido si se ha dividido en 
dos (o más) subsistemas, denominados particiones, que 
carecen de conexión entre ellas. Téngase en cuenta que, 
con esta definición, cada subsistema puede consistir en 
un solo nodo. 


19.4. PROTOCOLOS DE COMPROMISO 


Si hay que asegurar la atomicidad, todos los sitios en 
los que se ejecute una transacción T deben coincidir en 
el resultado final de la ejecución. T debe comprometer¬ 
se en todos los sitios o abortarse en todos los sitios. Para 
asegurar esta propiedad el coordinador de transaccio¬ 
nes de T debe ejecutar un protocolo de compromiso. 

Entre los protocolos de compromiso más sencillos y 
más utilizados está el protocolo de compromiso de dos 
fases (C2F), que se describe en el Apartado 19.4.1. Una 
alternativa es el protocolo de compromiso de tres fases 
(C3F), que evita ciertos inconvenientes del protocolo 
C2F pero añade complejidad y sobrecarga. El Aparta¬ 
do 19.4.2 describe brevemente el protocolo C3F. 

19.4.1. Compromiso de dos fases 

En primer lugar se describe el modo en que opera el 
protocolo de compromiso de dos fases (C2F) durante el 


funcionamiento normal, luego describe el modo en que 
maneja los fallos y, finalmente, la manera en que eje¬ 
cuta la recuperación y el control de la concurrencia. 

Considérese una transacción T iniciada en el sitio S¡, 
en que el coordinador de transacciones es C¡. 

19.4.1.1. El protocolo de compromiso 

Cuando T completa su ejecución (es decir, cuando todos 
los sitios en los que se ha ejecutado T informan a Ci de 
que T se ha completado) Ci inicia el protocolo C2F. 

• Fase 1. Ci añade el registro <T preparar> al regis¬ 
tro histórico y obliga a guardar el registro histórico 
en un lugar de almacenamiento estable. Entonces 
envía un mensaje preparar T a todos los sitios en los 
que se ha ejecutado T. Al recibir este mensaje el ges¬ 
tor de transacciones del sitio determina si desea com- 
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prometer su parte de T. Si la respuesta es negativa, 
añade un registro <no T> al registro histórico y res¬ 
ponde enviando a C¡ el mensaje abortar T. Si la res¬ 
puesta es sí, añade un registro <T preparada> al 
registro histórico y obliga a que el registro históri¬ 
co (con todos los registros del registro histórico 
correspondientes a T) se guarde en un almacena¬ 
miento estable. El gestor de transacciones contesta 
entonces a Ci con el mensaje T preparada. 

• Fase 2. Cuando Ci recibe las respuestas al men¬ 
saje preparar T de todos los sitios, o cuando ha 
transcurrido un intervalo de tiempo especificado 
con anterioridad desde que se envió el mensaje 
preparar T, C¡ puede determinar si la transacción 
T puede comprometerse o abortarse. La transac¬ 
ción T puede comprometerse si C¡ ha recibido el 
mensaje T preparada de todos los sitios partici¬ 
pantes. En caso contrario, la transacción T debe 
abortarse. En función del resultado, se añade al 
registro histórico un registro <T comprometida> 
o un registro <T abortada> y se obliga a que el 
registro histórico se guarde en un almacenamien¬ 
to estable. En este momento el destino de la tran¬ 
sacción ya se ha sellado. A partir de este momen¬ 
to el coordinador envía un mensaje comprometer 
T o abortar T a todos los sitios participantes. Cuan¬ 
do un sitio recibe ese mensaje, lo guarda en el 
registro histórico. 

Los sitios en los que se ejecutó T pueden abortarla 
de manera incondicional en cualquier momento antes 
de enviar el mensaje T preparada al coordinador. Una 
vez enviado el mensaje, se dice que la transacción está 
en estado preparado en el sitio. El mensaje T prepa¬ 
rada constituye, en realidad, un compromiso del sitio 
de seguir la orden del coordinador de comprometer T o 
de abortarla. Para realizar ese compromiso primero hay 
que guardar en un almacenamiento estable la informa¬ 
ción necesaria. En caso contrario, si el sitio fallara tras 
enviar el mensaje V preparada, puede que no fuera capaz 
de cumplir su promesa. Además, los bloqueos adquiri¬ 
dos por la transacción deben mantenerse hasta que se 
complete la transacción. 

Dado que se exige la unanimidad para comprome¬ 
ter una transacción, el destino de T queda sellado en 
cuanto un sitio responda abortar T. Dado que el sitio 
coordinador S¡ es uno de los sitios en los que se ha eje¬ 
cutado T, el coordinador puede decidir unilateralmen¬ 
te abortar T. El veredicto final sobre T se determina en 
el momento en que el coordinador lo escribe (com¬ 
prometer o abortar) en el registro histórico y obliga a 
guardar el veredicto en un almacenamiento estable. En 
algunas implementaciones del protocolo C2F un sitio 
envía el mensaje acuse-de-recibo T al coordinador al 
final de la segunda fase del protocolo. Cuando el coor¬ 
dinador recibe el mensaje acuse-de-recibo T de todos 
los sitios, añade el registro <T completada> al regis¬ 
tro histórico. 


19.4.1.2. Tratamiento de los íallos 

El protocolo C2F responde de modo diferente a diver¬ 
sos tipos de fallos: 

• Fallo de un sitio participante. Si el coordinador C¡ 
detecta que un sitio ha fallado emprende las accio¬ 
nes siguientes. Si el sitio falla antes de responder a 
C¡ con el mensaje T preparada, el coordinador da por 
supuesto que ha respondido con el mensaje abortar 
T. Si el sitio falla después de que el coordinador haya 
recibido del sitio el mensaje T preparada, el coordi¬ 
nador ejecuta el resto del protocolo de compromiso 
de manera normal, ignorando el fallo del sitio. 

Cuando un sitio participante S k se recupera de 
un fallo debe examinar su registro histórico para 
determinar el destino de las transacciones que se 
hallaban en trance de ejecución cuando se produ¬ 
jo el fallo. Supóngase que T es una de esas tran¬ 
sacciones. Se toman en consideración cada uno de 
los casos posibles: 

— El registro histórico contiene un registro <T 
comprometidas En este caso el sitio ejecuta 
rehacer(T). 

— El registro histórico contiene un registro <T abor¬ 
tadas En este caso el sitio ejecuta deshaced 7’). 
— El registro histórico contiene un registro <7 pre¬ 
paradas En este caso el sitio debe consultar con 
C¡ para determinar el destino de T. Si C¡ está acti¬ 
vo, notifica a S k si 7 se comprometió o se abor¬ 
tó. En el primer caso, ejecuta rehacer(T); en el 
segundo, ejecuta deshacer(7’). Si C¡ no está acti¬ 
vo, S k debe intentar hallar el destino de T con¬ 
sultando a otros sitios. Lo hace enviando un men¬ 
saje consulta-estado T a todos los sitios del 
sistema. Al recibir ese mensaje cada sitio debe 
consultar su registro histórico para determinar 
si allí se ejecutó T y, en caso afirmativo, si se 
comprometió o abortó. Luego notifica a S k el 
resultado. Si ningún sitio tiene la información 
correspondiente (es decir, si T se comprometió 
o se abortó), S k no puede abortar ni comprome¬ 
ter T. La decisión sobre T se pospone hasta que 
S t pueda obtener la información necesaria. Por 
tanto, S k debe volver a enviar de manera perió¬ 
dica el mensaje consulta-estado a los demás 
sitios. Lo sigue haciendo hasta que un sitio que 
contenga la información necesaria se recupere. 
Téngase en cuenta que el sitio en el que reside 
C¡ siempre tiene la información necesaria. 

— El registro histórico no contiene ningún registro 
de control (abortada, comprometida, prepara¬ 
da) relativo a T. Por tanto, se sabe que S k falló 
antes de responder al mensaje preparar T de C¡. 
Dado que el fallo de S k evita el envío de la res¬ 
puesta, de acuerdo con el algoritmo, C¡ debe 
abortar T. Por tanto, S k debe ejecutar deshaced,7). 
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Fallo del coordinador. Si el coordinador falla 
durante la ejecución del protocolo de compromiso 
para la transacción T, los sitios participantes deben 
decidir el destino de T. Se verá que, en ciertos casos, 
los sitios participantes no pueden decidir si com¬ 
prometer o abortar T, y, por tanto, deben esperar a 
la recuperación del coordinador que ha fallado. 

— Si un sitio activo contiene un registro <T com- 
prometida> en su registro histórico, T debe 
comprometerse. 

— Si un sitio activo contiene un registro <T abor- 
tada> en su registro histórico, T debe abortarse. 

— Si algún sitio activo no contiene el registro <T 
preparada> en su registro histórico, el coordi¬ 
nador C¡ que ha fallado no puede haber deci¬ 
dido comprometer T, ya que un sitio que no 
contenga el registro <T preparada> en su regis¬ 
tro histórico no puede haber enviado el men¬ 
saje T preparada a C¡. No obstante, puede que 
el coordinador haya decidido abortar T, pero 
no comprometer T. En vez de esperar a que se 
recupere C„ resulta preferible abortar T. 

— Si no se da ninguno de los casos anteriores todos 
los sitios activos deben tener un registro <T pre- 
parada> en sus registros, pero ningún otro regis¬ 
tro de control (como <T abortada> o <T com¬ 
prometida;»). Dado que el coordinador ha 
fallado, resulta imposible determinar si se ha 
tomado alguna decisión, y en caso de haberse 
tomado, averiguar la que era, hasta que se recu¬ 
pere el coordinador. Por tanto, los sitios activos 
deben esperar a que se recupere C¡. Dado que 
el destino de T sigue siendo dudoso, puede 
seguir consumiendo recursos del sistema. Por 
ejemplo, si se emplean bloqueos, T puede con¬ 
servar los bloqueos sobre los datos en los sitios 
activos. Esta situación no es deseable, dado que 
pueden pasar horas o días antes de que C¡ vuel¬ 
va a estar activo. Durante ese tiempo puede que 
otras transacciones se vean obligadas a esperar 
a T. En consecuencia, puede que los elementos 
de datos no estén disponibles, no sólo en el sitio 
que ha fallado (C¡), sino también en los sitios 
activos. Esta situación se denomina problema 
del bloqueo, ya que T queda bloqueada mien¬ 
tras espera la recuperación del sitio C¡. 

División de la red. Cuando una red queda dividi¬ 
da caben dos posibilidades: 

1. El coordinador y todos los sitios participantes 
siguen en una de las particiones. En este caso, 
el fallo no tiene ningún efecto sobre el proto¬ 
colo de compromiso. 

2. El coordinador y los participantes quedan en 
varias particiones. Desde el punto de vista de los 


sitios de una de las particiones, parece como si 
los sitios de las demás particiones hubieran falla¬ 
do. Los sitios que no se hallan en la partición que 
contiene al coordinador sencillamente ejecutan 
el protocolo para tratar el fallo del coordinador. 
El coordinador y los sitios que se hallan en su 
misma partición siguen el protocolo de com¬ 
promiso habitual, dando por supuesto que los 
sitios de las demás particiones han fallado. 

Por tanto, el mayor inconveniente del protocolo C2F 
es que el fallo del coordinador puede dar lugar a un blo¬ 
queo, en el que puede que haya que retrasar la decisión 
sobre comprometer o abortar T hasta que se recupere C¡. 

19.4.1.3. Recuperación y control 
de la concurrencia 

Cuando se reinicia un sitio que ha fallado se puede lle¬ 
var a cabo la recuperación, por ejemplo, utilizando el 
algoritmo de recuperación descrito en el Apartado 17.9. 
Para tratar con los protocolos de compromiso distri¬ 
buidos (como C2F y C3F),el procedimiento de recupe¬ 
ración debe tratar de manera especial las transacciones 
dudosas; las transacciones dudosas son transacciones 
para las que no se encuentra ningún registro < T pre¬ 
parada;», <T comprometida;» ni <7 abortada;» en el regis¬ 
tro histórico. El sitio que se recupera debe determinar 
la situación comprometer-abortar de esas transacciones, 
como se describe en el Apartado 19.4.1.2. 

Sin embargo, si se realiza la recuperación como se 
acaba de describir, no puede comenzar el procesamien¬ 
to normal de transacciones en el sitio hasta que se hayan 
comprometido o deshecho todas las transacciones dudo¬ 
sas. La averiguación de la situación de las transacciones 
dudosas puede tardar mucho tiempo, dado que puede que 
haya que entrar en contacto con varios sitios. Además, 
si ha fallado el coordinador, y ningún otro sitio tiene 
información sobre la situación comprometida-abortada 
de una transacción incompleta, se podría bloquear la recu¬ 
peración si se utiliza C2F. En consecuencia, puede que 
el sitio que lleva a cabo la recuperación de reinicio que¬ 
de inutilizable durante un largo periodo de tiempo. 

Para evitar este problema los algoritmos de recupera¬ 
ción suelen ofrecer soporte para anotar en el registro his¬ 
tórico información sobre los bloqueos (se da por supues¬ 
to que se utilizan los bloqueos para el control de la 
concurrencia). En lugar de escribir en el registro históri¬ 
co un registro <T preparada:», el algoritmo escribe en el 
registro histórico un registro <T preparada, L>, donde L 
es una lista de todos los bloqueos de escritura que tiene 
la transacción T cuando se escribe el registro. En el 
momento de la recuperación, tras llevar a cabo las accio¬ 
nes de recuperación, se renuevan para cada transacción 
dudosa T todos los bloqueos de escritura anotados en el 
registro <T preparada, L> del registro histórico. 

Después de que se haya completado la renovación 
de los bloqueos para todas las transacciones dudosas 
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puede comenzar en el sitio el procesamiento de las tran¬ 
sacciones, incluso antes de que se determine el estado 
comprometida-abortada de las transacciones dudosas. El 
comprometer o deshacer las transacciones dudosas se 
realiza de manera concurrente con la ejecución de las 
transacciones nuevas. Así, la recuperación del sitio es 
más rápida y no se bloquea nunca. Obsérvese que las tran¬ 
sacciones nuevas que tengan un conflicto de bloqueos 
con cualquier bloqueo de escritura que tengan las tran¬ 
sacciones dudosas no podrán progresar hasta que se 
hayan comprometido o deshecho las transacciones dudo¬ 
sas con las que estén en conflicto. 

19.4.2. Compromiso de tres fases 

El protocolo de compromiso de tres fases (C3F) es una 
extensión del protocolo de compromiso de dos fases 
que evita el problema del bloqueo con determinadas 
suposiciones. En concreto, se supone que no se produ¬ 
ce ninguna fragmentación de la red y que no fallan más 
de k sitios, donde k es un número predeterminado. Con 
estas suposiciones el protocolo evita el bloqueo intro¬ 
duciendo una tercera fase adicional en que se implican 
varios sitios en la decisión de comprometer. En lugar 
de anotar directamente la decisión de comprometer en 
su almacenamiento persistente, el coordinador se ase¬ 
gura antes de que al menos otros k sitios sepan que pre¬ 
tende comprometer la transacción. Si el coordinador 
falla, los sitios restantes seleccionan primero un nuevo 
coordinador. Este nuevo coordinador verifica el estado 
del protocolo a partir de los demás sitios; si el coordi¬ 
nador había decidido comprometer, al menos uno de los 
otros k sitios a los que informó estará funcionando y 
asegurará que se respete la decisión de comprometer. 
El nuevo coordinador vuelve a iniciar la tercera fase del 
protocolo si algún sitio sabía que el antiguo coordina¬ 
dor pretendía comprometer la transacción. En caso con¬ 
trario, el nuevo coordinador aborta la transacción. 

Aunque el protocolo C3F tiene la propiedad desea¬ 
ble de no bloquearse a menos que fallen k sitios, tiene 
el inconveniente de que una división de la red parece lo 
mismo que el fallo de más de k sitios, lo que puede pro¬ 
ducir un bloqueo. El protocolo también tiene que imple- 
mentarse con mucho cuidado para asegurarse de que la 
división de la red (o el fallo de más de k sitios) no pro¬ 
voque inconsistencias, de modo que una transacción se 
comprometa en una de las particiones y se aborte en 
otra. Debido a la sobrecarga que implica el protocolo 
C3F, no se utiliza mucho. Véanse las notas bibliográfi¬ 
cas para hallar referencias que den más detalles del pro¬ 
tocolo C3F. 

19.4.3. Modelos alternativos 

del procesamiento de transacciones 

Para muchas aplicaciones el problema del bloqueo del 
compromiso de dos fases no resulta aceptable. El pro¬ 
blema en este caso es la idea de una sola transacción 


que trabaja en varios sitios. En este apartado se descri¬ 
be el modo de utilizar la mensajería persistente para 
evitar el problema del compromiso distribuido y luego 
describe brevemente el problema más importante de los 
flujos de trabajo', los flujos de trabajo se consideran con 
mayor detalle en el Apartado 24.2. 

Para comprender la mensajería persistente considé¬ 
rese el modo en que se podrían transferir fondos entre 
dos bancos diferentes, cada uno con su propia compu¬ 
tadora. Un enfoque es hacer que la transacción abarque 
los dos sitios y utilizar el compromiso de dos fases para 
asegurar la atomicidad. Sin embargo, puede que la tran¬ 
sacción tenga que actualizar todo el saldo del banco y 
el bloqueo podría tener un grave impacto en las demás 
transacciones de cada banco, dado que casi todas las 
transacciones de los bancos actualizan el saldo total del 
banco. 

Para comparar, considérese el modo en que se pro¬ 
duce la transferencia de fondos mediante un cheque. El 
banco deduce en primer lugar el importe del cheque del 
saldo disponible e imprime un cheque. El cheque se 
transfiere físicamente al otro banco, donde se deposita. 
Tras comprobar el cheque, el banco aumenta el saldo 
local en el importe del cheque. El cheque constituye un 
mensaje enviado entre los dos bancos. Para que los fon¬ 
dos no se pierdan ni se aumenten de manera incorrecta 
no se debe perder el cheque ni se debe duplicar ni depo¬ 
sitar más de una vez. Cuando las computadoras de los 
bancos se hallan conectadas mediante una red, los men¬ 
sajes persistentes ofrecen el mismo servicio que los che¬ 
ques (pero mucho más rápido, por supuesto). 

Los mensajes persistentes son mensajes que tienen 
garantizada su entrega al destinatario exactamente una 
sola vez (ni más ni menos), independientemente de los 
fallos, la transacción que envía el mensaje «compro¬ 
meter» tiene que ofrecer la garantía de no efectuar la 
entrega si la transacción se aborta. Las técnicas de recu¬ 
peración de bases de datos se utilizan para implemen- 
tar la mensajería persistente por encima de los canales 
normales de la red, como se verá en breve. A diferencia 
de esto, los mensajes normales pueden perderse o, inclu¬ 
so, entregarse varias veces en algunas circunstancias. 

El manejo de los errores resulta más complicado con 
la mensajería persistente que con el compromiso de dos 
fases. Por ejemplo, si la cuenta en la que hay que ingre¬ 
sar el cheque se ha cerrado, hay que devolver el cheque 
a la cuenta que lo originó y volver a cargar su importe 
en ella. Por tanto, ambos sitios deben disponer de códi¬ 
go para el manejo de errores y con código para mane¬ 
jar los mensajes persistentes. Sin embargo, con el com¬ 
promiso de dos fases, el error lo detectaría la transacción, 
que no deduciría nunca el importe del cheque de la pri¬ 
mera cuenta. 

Los tipos de condiciones de excepción que pueden 
surgir dependen de la aplicación, por lo que no es posi¬ 
ble que el sistema de bases de datos maneje las excep¬ 
ciones de manera automática. Los programas de apli¬ 
caciones que envían y reciben los mensajes persistentes 
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deben incluir código para manejar las condiciones de 
excepción y devolver el sistema a un estado consisten¬ 
te. Por ejemplo, no resulta aceptable que se pierda el 
dinero que se transfiere si se ha cerrado la cuenta recep¬ 
tora; hay que devolver el dinero a la cuenta ordenante, 
y si ello no resulta posible por algún motivo, hay que 
advertir a los empleados del banco para que resuelvan 
manualmente la situación. 

Hay muchas aplicaciones en que la ventaja de la eli¬ 
minación del bloqueo merece ampliamente el esfuerzo 
adicional de implementar los sistemas que utilizan los 
mensajes persistentes. De hecho, pocas organizaciones 
aceptarían soportar el compromiso de dos fases para 
transacciones que se originen fuera de ellas, dado que 
los fallos pueden producir el bloqueo del acceso a los 
datos locales. La mensajería persistente, por tanto, 
desempeña un papel importante en la ejecución de las 
transacciones que atraviesan las fronteras de las orga¬ 
nizaciones. 

Los flujos de trabajo proporcionan un modelo gene¬ 
ral de procesamiento de las transacciones que implican 
a varios sitios y, posiblemente, el procesamiento manual 
por los empleados de determinadas fases del proceso. 
Por ejemplo, cuando un banco recibe la solicitud de un 
crédito hay muchos pasos que debe dar, incluido el con¬ 
tacto con agencias extemas de calificación de créditos, 
antes de aceptar o rechazar la solicitud. Los pasos, en 
su conjunto, forman un flujo de trabajo. Los flujos de 
trabajo se estudian con mayor detalle en el Apartado 
2.4.2. También se observa que la mensajería consisten¬ 
te forma la base subyacente a los flujos de trabajo en 
los entornos distribuidos. 

Se considerará ahora la implementación de la men¬ 
sajería persistente. La mensajería persistente pueden irnple- 
mentarla los siguientes protocolos por encima de estruc¬ 
turas de mensajería que no sean dignas de confianza, que 
pueden perder mensajes o entregarlos varias veces: 

• Protocolo de sitio enviante. Cuando una transac¬ 
ción desea enviar un mensaje persistente escribe 
un registro que contiene el mensaje en una rela¬ 
ción especial mensajes-a-enviar, en lugar de enviar 
el mensaje directamente. También se le da al men¬ 
saje un identificador de mensaje único. 

Un proceso de entrega de mensajes controla la 
relación y, cuando se halla un mensaje nuevo, lo 
envía a su destino. Los mecanismos habituales de 
control de la concurrencia de las bases de datos 
aseguran que el proceso del sistema lea el mensa¬ 
je tan sólo una vez que la transacción que escribió 


el mensaje se haya comprometido; si la transac¬ 
ción se aborta, el mecanismo habitual de recupe¬ 
ración borra el mensaje de la relación. 

El proceso de eliminación de mensajes sólo eli¬ 
mina los mensajes de la relación una vez que ha 
recibido un acuse de recibo del sitio de destino. Si 
no lo hace, pasado cierto tiempo vuelve a enviar 
el mensaje. Repite este proceso hasta que recibe 
un acuse de recibo. En caso de fallo permanente 
el sistema decide, pasado algún tiempo, que el 
mensaje no puede entregarse. Entonces se invoca 
al código para el manejo de excepciones propor¬ 
cionado por la aplicación para tratar el fallo. 

La escritura del mensaje en una relación y su 
procesamiento tan sólo después de comprometer 
la transacción asegura que el mensaje se entregue 
si y sólo si la transacción se compromete. Su envío 
repetido garantiza que se entregue aunque haya 
fallos (temporales) del sistema o de la red. 

• Protocolo de sitio receptor. Cuando un sitio reci¬ 
be un mensaje persistente ejecuta una transacción 
que añade el mensaje a la relación especial men¬ 
sajes-recibidos, siempre que no se halle ya pre¬ 
sente en la relación (el identificador único de men¬ 
sajes detecta los duplicados). Una vez que la 
transacción se compromete, o si el mensaje ya se 
hallaba en la relación, el sitio receptor devuelve 
un acuse de recibo al sitio enviante. 

Hay que tener en cuenta que enviar el acuse de 
recibo antes de que la transacción se comprometa 
no resulta seguro, ya que un fallo del sistema pudie¬ 
ra hacer que el mensaje se perdiera. La compro¬ 
bación de si el mensaje se ha recibido previamen¬ 
te resulta fundamental para evitar entregas 
múltiples del mensaje. 

En muchos sistemas de mensajería resulta posi¬ 
ble que los mensajes se retrasen de manera arbi¬ 
traria, aunque tales retrasos sean muy improbables. 
Por tanto, para asegurarse, no se debe eliminar nun¬ 
ca el mensaje de la relación mensajes-recibidos. 
Su eliminación pudiera hacer que no se detectara 
una entrega duplicada. Pero, como consecuencia, 
la relación mensajes-recibidos puede crecer de 
manera indefinida. Para resolver este problema se 
da a cada mensaje una marca temporal y, si la mar¬ 
ca temporal de un mensaje recibido es más anti¬ 
gua que algún punto arbitrario de corte, se descarta 
el mensaje. Todos los mensajes de la relación men¬ 
sajes-recibidos que sean más antiguos que el pun¬ 
to de corte pueden eliminarse. 
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19.5. CONTROL DE LA CONCURRENCIA EN LAS BASES DE DATOS 
DISTRIBUIDAS 


En este apartado se muestra el modo en que algunos de 
los esquemas de control de la concurrencia que se dis¬ 
cuten en el Capítulo 16 pueden modificarse para que 
puedan utilizarse en entornos distribuidos. Se da por 
supuesto que cada sitio participa en la ejecución de un 
protocolo de compromiso para asegurar la atomicidad 
global de las transacciones. 

Los protocolos que se describen en este apartado 
necesitan que se hagan actualizaciones de todas las répli¬ 
cas de los elementos de datos. Si ha fallado algún sitio 
que contiene una réplica de un elemento de datos, no se 
pueden procesar las actualizaciones del elemento de 
datos. En el Apartado 19.6 se describen los protocolos 
que pueden continuar el procesamiento de las transac¬ 
ciones aunque haya fallado algún sitio o algún enlace, 
lo que proporciona una gran disponibilidad. 

19.5.1. Protocolos de bloqueo 

Los diferentes protocolos de bloqueo descritos en el 
Capítulo 16 se pueden utilizar en entornos distribuidos. 
La única modificación que hay que incorporar es el 
modo en que el gestor de bloqueos trata los datos repli¬ 
cados. Se presentan varios esquemas posibles que son 
aplicables a entornos en que los datos puedan replicar¬ 
se en varios sitios. Al igual que en el Capítulo 16 se dará 
por supuesto la existencia de los modos de bloqueo com¬ 
partido y exclusivo. 

19.5.1.1. Enfoque de gestor único de bloqueos 

En el enfoque de gestor único de bloqueos el sistema 
mantiene un único gestor de bloqueos que reside en un 
sitio único escogido (digamos S¡). Todas las solicitudes 
de bloqueo y de desbloqueo se realizan en el sitio S¡. 
Cuando una transacción necesita bloquear un elemen¬ 
to de datos envía una solicitud de bloqueo a S¡. El ges¬ 
tor de bloqueos determina si se puede conceder el blo¬ 
queo de manera inmediata. Si se puede conceder el 
bloqueo, el gestor de bloqueos envía un mensaje con 
ese objeto al sitio en el que se inició la solicitud de blo¬ 
queo. En caso contrario, la solicitud se retrasa hasta que 
puede concederse, en cuyo momento se envía un men¬ 
saje al sitio en el que se inició la solicitud de bloqueo. 
La transacción puede leer el elemento de datos de cual¬ 
quiera de los sitios en los que residen las réplicas del 
elemento de datos. En caso de una operación de escri¬ 
tura deben implicarse en la escritura todos los sitios en 
los que residen réplicas del elemento de datos. 

El esquema tiene las ventajas siguientes: 

• Implementación sencilla. Este esquema necesita 
dos mensajes para tratar las solicitudes de bloqueo 
y sólo uno para las de desbloqueo. 


• Tratamiento sencillo de los interbloqueos. Dado 
que todas las solicitudes de bloqueo y de desblo¬ 
queo se realizan en un solo sitio, se pueden apli¬ 
car directamente a este entorno los algoritmos de 
tratamiento de los interbloqueos estudiados en el 
Capítulo 16. 

Los inconvenientes del esquema son: 

• Cuello de botella. El sitio S¡ se transforma en un 
cuello de botella, dado que todas las solicitudes 
deben procesarse allí. 

• Vulnerabilidad. Si el sitio S¡ falla se pierde el con¬ 
trolador de la concurrencia. Se debe detener el pro¬ 
cesamiento o utilizar un esquema de recuperación 
de modo que pueda asumir la administración de 
los bloqueos un sitio de respaldo, como se descri¬ 
be en el Apartado 19.6.5. 

19.5.1.2. Gestor distribuido de bloqueos 

Se puede lograr un compromiso entre las ventajas y los 
inconvenientes ya mencionados mediante el enfoque 
del gestor distribuido de bloqueos, en el que la fun¬ 
ción de gestor de bloqueos se halla distribuida entre 
varios sitios. 

Cada sitio mantiene un gestor de bloqueos local cuya 
función es gestionar las solicitudes de bloqueo y de des¬ 
bloqueo para los elementos de datos que se almacenan 
en ese sitio. Cuando una transacción desea bloquear el 
elemento de datos Q, que no está replicado y reside en 
el sitio S¡, se envía un mensaje al gestor de bloqueos del 
sitio S¡ para solicitarle un bloqueo (en un modo de blo¬ 
queo determinado). Si el elemento de datos Q está blo¬ 
queado en un modo incompatible, se retrasa la solici¬ 
tud hasta que puede concederse. Una vez se ha 
determinado que la solicitud de bloqueo puede conce¬ 
derse el gestor de bloqueos devuelve un mensaje al sitio 
que ha iniciado la solicitud que indica que ha concedi¬ 
do la solicitud de bloqueo. 

Hay varios modos alternativos de tratar con la répli¬ 
ca de los elementos de datos, que se estudian en los apar¬ 
tados 19.5.1.3 a 19.5.1.6. 

El esquema del gestor distribuido de bloqueos tiene 
la ventaja de su implementación sencilla y reduce el gra¬ 
do en el que el coordinador constituye un cuello de bote¬ 
lla. Tiene una sobrecarga razonablemente baja, ya que 
sólo necesita dos transferencias de mensajes para tratar 
las solicitudes de bloqueo y una transferencia de men¬ 
saje para las de desbloqueo. No obstante, el tratamien¬ 
to de los interbloqueos resulta más complejo, dado que 
las solicitudes de bloqueo y de desbloqueo ya no se rea¬ 
lizan en un solo sitio. Puede haber interbloqueos entre 
sitios aunque no haya interbloqueos en ninguno de los 
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sitios. Los algoritmos de tratamiento de los interblo¬ 
queos estudiados en el Capítulo 16 deben modificarse, 
como se discutirá en el Apartado 19.5.4. para detectar 
los interbloqueos globales. 

19.5.1.3. Copia principal 

Cuando un sistema utiliza la réplica de datos se puede 
escoger una de las réplicas como copia principal. Así, 
para cada elemento de datos Q la copia principal de Q 
debe residir exactamente en un sitio, que se denomina 

sitio principal de Q. 

Cuando una transacción necesita bloquear un ele¬ 
mento de datos Q solicita un bloqueo en el sitio princi¬ 
pal de Q. Como ya se ha visto, la respuesta a la solici¬ 
tud se retrasa hasta que pueda concederse. 

Por tanto, la copia principal permite que el control 
de concurrencia de los datos replicados se trate como 
el de los datos no replicados. Esta semejanza permite 
una implementación sencilla. No obstante, si falla el 
sitio principal de Q, Q queda inaccesible, aunque otros 
sitios que contengan réplicas estén accesibles. 

19.5.1.4. Protocolo de mayoría 

El protocolo de mayoría funciona de la manera siguien¬ 
te. Si el elemento de datos Q se replica en n sitios dife¬ 
rentes se debe enviar un mensaje de solicitud de blo¬ 
queo a más del 50 por 100 de los n sitios en los que se 
almacena Q. Cada gestor de bloqueos determina si se 
puede conceder el bloqueo de manera inmediata (en lo 
que a él se refiere). Como ya se ha visto, la respuesta se 
retrasa hasta que se pueda conceder la solicitud. La tran¬ 
sacción no se opera en Q hasta que logre obtener un blo¬ 
queo en la mayoría de las réplicas de Q. 

Por el momento se asume que las escrituras se rea¬ 
lizan en todas las réplicas, exigiendo que todos los sitios 
que contengan réplicas estén disponibles. Sin embargo, 
la mayor ventaja del protocolo de mayoría es que se 
puede extender para tratar los fallos de los sitios, como 
se verá en el Apartado 19.6.1. Este esquema trata los 
datos replicados de manera descentralizada, con lo que 
evita los inconvenientes del control centralizado. No 
obstante, presenta los siguientes inconvenientes: 

• Implementación. El protocolo de mayoría es más 
complicado de implementar que los esquemas ante¬ 
riores. Necesita 2 (n / 2 + 1) mensajes para mane¬ 
jar las solicitudes de bloqueo y (n / 2 + 1) mensa¬ 
jes para manejar las solicitudes de desbloqueo. 

• Tratamiento de los interbloqueos. Además del 
problema de los interbloqueos locales debidos al 
empleo del enfoque del gestor distribuido de blo¬ 
queos, puede que se produzca un interbloqueo aun¬ 
que sólo se esté bloqueando un elemento de datos. 
A modo de ejemplo, considérese un sistema con 
cuatro sitios y réplica completa. Supóngase que 
las transacciones T { y T 2 desean bloquear el ele¬ 
mento de datos Q en modo exclusivo. Puede que 


la transacción T¡ tenga éxito en bloquear Q en los 
sitios Sj y S 3 , mientras que puede que la transac¬ 
ción T 2 consiga bloquear Q en los sitios S 2 y S 4 . 
Cada una de ellas deberá esperar a adquirir el ter¬ 
cer bloqueo; por tanto, se ha producido un inter¬ 
bloqueo. Por fortuna, se pueden evitar estos inter¬ 
bloqueos con relativa facilidad exigiendo que todos 
los sitios soliciten los bloqueos de las réplicas de 
un elemento de datos en el mismo orden prede¬ 
terminado. 

19.5.1.5. Protocolo sesgado 

El protocolo sesgado es otro enfoque del manejo de las 
réplicas. La diferencia con el protocolo de mayoría es 
que se concede un tratamiento más favorable a las soli¬ 
citudes de bloqueos compartidos que a las solicitudes 
de bloqueos exclusivos. 

• Bloqueos compartidos. Cuando una transacción 
necesita bloquear un elemento de datos Q simple¬ 
mente solicita un bloqueo de Q al gestor de blo¬ 
queos de un sitio que contenga una réplica de Q. 

• Bloqueos exclusivos. Cuando una transacción 
necesita bloquear el elemento de datos Q solicita 
un bloqueo de Q al gestor de bloqueos de todos los 
sitios que contienen una réplica de Q. 

Como ya se ha visto, la respuesta a la solicitud se 
retrasa hasta que pueda concederse. El esquema sesga¬ 
do tiene la ventaja de imponer menos sobrecarga a las 
operaciones de lectura que el protocolo de mayoría. Este 
ahorro resulta especialmente significativo en los casos 
frecuentes en los que la frecuencia de las operaciones 
de lectura es mucho mayor que la de las operaciones de 
escritura. No obstante, la sobrecarga adicional sobre las 
operaciones de escritura supone un inconveniente. Ade¬ 
más, el protocolo sesgado comparte el inconveniente de 
la complejidad en el manejo de interbloqueos con el 
protocolo de mayoría. 

19.5.1.6. Protocolo de consenso de quorum 

El protocolo de consenso de quorum es una generali¬ 
zación del protocolo de mayoría. El protocolo de con¬ 
senso de quorum asigna a cada sitio un peso no negati¬ 
vo. Asigna a las operaciones de lectura y de escritura 
del elemento x dos enteros, denominados quorum de 
lectura Q , y quorum de escritura Q e , que deben cum¬ 
plir la condición siguiente, donde S es el peso total de 
todos los sitios en los que reside x: 

Q, + Qe> Sy2* Q e > S 

Para ejecutar una operación de lectura deben blo¬ 
quearse suficientes réplicas como para que su peso total 
sea > Q¡. Para ejecutar una operación de escritura se 
deben bloquear suficientes réplicas como para que su 
peso total sea > Q e . 
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Una ventaja del enfoque de consenso de quorum es 
que puede permitir reducir de manera selectiva el coste 
de las operaciones de bloqueo de lectura o de escritura 
definiendo de manera adecuada los quorum de lectura y 
de escritura. Por ejemplo, con un quorum de lectura 
pequeño las operaciones de lectura necesitan obtener 
menos bloqueos, pero el quorum de escritura será mayor, 
por lo que las operaciones de escritura necesitan obtener 
más bloqueos. Además, si se asignan pesos más eleva¬ 
dos a algunos sitios (por ejemplo, a los que tengan menos 
posibilidad de fallar), hay que tener acceso a menos sitios 
para adquirir los bloqueos. 

De hecho, al definir los pesos y los quorum de mane¬ 
ra adecuada, el protocolo de consenso de quorum pue¬ 
de simular el protocolo de mayoría y los protocolos ses¬ 
gados. 

19.5.2. Marcas temporales 

La idea principal tras el esquema de marcas temporales 
del Apartado 16.2 es que se concede a cada transacción 
una marca temporal única que el sistema utiliza para 
decidir el orden de secuenciación. La primera tarea, por 
tanto, al generalizar el esquema centralizado a un esque¬ 
ma distribuido es desarrollar un esquema para generar 
marcas temporales únicas. Luego, los diferentes proto¬ 
colos pueden operar directamente en el entorno no repli¬ 
cado. 

Hay dos métodos principales para la generación de 
marcas temporales únicas, uno centralizado y otro dis¬ 
tribuido. En el esquema centralizado un solo sitio dis¬ 
tribuye las marcas temporales. El sitio puede utilizar 
un contador lógico o su propio reloj local con esta fina¬ 
lidad. 

En el esquema distribuido cada sitio genera una mar¬ 
ca temporal local única mediante un contador lógico o 
el reloj local. La marca temporal global única se obtie¬ 
ne concatenando la marca temporal local única con el 
identificador del sitio, que también debe ser único (Figu¬ 
ra 19.2). El orden de concatenación es importante. El 
identificador del sitio se utiliza en la posición menos 
significativa para asegurar que las marcas temporales 
globales generadas en un sitio no sean siempre mayo¬ 
res que las generadas en otro. Compárese esta técnica 
para la generación de marcas temporales únicas con la 
presentada en el Apartado 19.2.3 para la generación de 
nombres únicos. 


Puede que todavía surja algún problema si un sitio 
genera marcas temporales locales a una velocidad 
mayor que la de los demás sitios. En ese caso el con¬ 
tador lógico del sitio rápido será mayor que el de los 
demás sitios. Por tanto, todas las marcas temporales 
generadas por el sitio rápido serán mayores que las 
generadas por los demás sitios. Lo que se necesita es 
un mecanismo que asegure que las marcas temporales 
locales se generen de manera homogénea en todo el 
sistema. En cada sitio S¡ se define un reloj lógico (RL¡), 
que genera la marca temporal local única. El reloj lógi¬ 
co puede implementarse como un contador que se incre¬ 
mente después de generar una nueva marca temporal 
local. Para asegurar que los diferentes relojes lógicos 
estén sincronizados se exige que el sitio S¡ adelante su 
reloj lógico siempre que una transacción T¡ con la mar¬ 
ca temporal <x,y> visite ese sitio y x sea mayor que el 
valor actual de RL¡. En ese caso el sito S¡ adelanta su 
reloj lógico al valor x + 1. 

Si se utiliza el reloj del sistema para generar marcas 
temporales, éstas se asignarán de manera homogénea, 
dado que ningún sitio tiene un reloj del sistema que vaya 
rápido o lento. Dado que es posible que los relojes no 
sean totalmente exactos, se debe utilizar una técnica simi¬ 
lar a la de los relojes lógicos para asegurar que ningún 
reloj se adelante o se atrase mucho respecto de los demás. 

19.5.3. Réplica con grado de consistencia bajo 

Muchas bases de datos comerciales de hoy en día sopor¬ 
tan las réplicas, que pueden adoptar varias formas. Con 
la réplica maestro-esclavo la base de datos permite las 
actualizaciones en el sitio principal y las propaga de 
manera automática a las réplicas de los demás sitios. 
Las transacciones pueden leer las réplicas en los demás 
sitios, pero no se les permite actualizarlas. 

Una característica importante de esta réplica es que 
las transacciones no consiguen bloqueos en los sitios 
remotos. Para asegurar que las transacciones que se eje¬ 
cutan en los sitios réplicas vean una vista consistente 
(aunque quizás desactualizada) de la base de datos la 
réplica debe reflejar una instantánea consistente para 
las réplicas de los datos del sitio principal, es decir, la 
réplica debe reflejar todas las actualizaciones hasta una 
transacción dada en el orden de secuenciación. 

La base de datos puede estar configurada para pro¬ 
pagar las actualizaciones de manera inmediata una vez 


marca temporal 
local única 



FIGURA 19.2. Generación de marcas temporales únicas. 
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producidas en el sitio principal o para propagarlas sólo 
de manera periódica. 

La réplica maestro-esclavo resulta especialmente útil 
para distribuir información, por ejemplo desde una ofi¬ 
cina central a las sucursales de una organización. Otro 
empleo de esta forma de réplica es la creación de copias 
de la base de datos para ejecutar consultas de gran tama¬ 
ño, de modo que las consultas no interfieran con las tran¬ 
sacciones. Las actualizaciones deben propagarse de 
manera periódica (cada noche, por ejemplo) de modo 
que la propagación no interfiera con el procesamiento 
de las consultas. 

El sistema de bases de datos Oracle posee la sen¬ 
tencia create snapshot (crear instantánea), que puede 
crear una instantánea consistente para las transacciones 
de una relación, o de un conjunto de relaciones, en un 
sitio remoto. También soporta la actualización de ins¬ 
tantáneas, que puede hacerse volviendo a calcular la 
instantánea o actualizándola de manera incremental. 
Oracle soporta la actualización automática, bien conti¬ 
nuamente, bien a intervalos periódicos. 

Con la réplica multimaestro (también denominada 
réplica de actualización distribuida) se permiten las 
actualizaciones en cualquier réplica de los elementos 
de datos y se propagan de manera automática a todas 
las réplicas. Este modelo es el modelo básico utilizado 
para administrar las réplicas en las bases de datos dis¬ 
tribuidas. Las transacciones actualizan la copia local y 
el sistema actualiza las demás réplicas de manera trans¬ 
parente. 

Un modo de actualizar las réplicas es aplicar la actua¬ 
lización inmediata con el compromiso de dos fases, uti¬ 
lizando una de las técnicas de control de la concurren¬ 
cia distribuida que se han visto. Muchos sistemas de 
bases de datos utilizan el protocolo sesgado, en el que 
las operaciones de escritura tienen que bloquear y actua¬ 
lizar todas las réplicas y las operaciones de lectura blo¬ 
quean y leen cualquier réplica, como técnica de control 
de la concurrencia. 

Muchos sistemas de bases de datos ofrecen una for¬ 
ma alternativa de actualización: Actualizan en un sitio, 
con propagación perezosa de las actualizaciones a los 
demás sitios, en lugar de aplicar de manera inmediata 
las actualizaciones a todas las réplicas como parte de la 
transacción que lleva a cabo la actualización. Los esque¬ 
mas basados en la propagación perezosa permiten que 
continúe el procesamiento de las transacciones (inclui¬ 
das las actualizaciones) aunque un sitio quede desco¬ 
nectado de la red, lo que mejora la disponibilidad, pero, 
por desgracia, lo hacen a costa de la consistencia. Se 
suele seguir uno de estos dos enfoques cuando se utili¬ 
za la propagación perezosa: 

• Las actualizaciones de las réplicas se traducen en 
actualizaciones del sitio principal, que se propa¬ 
gan luego de manera perezosa a todas las réplicas. 

Este enfoque asegura que las actualizaciones 
de un elemento se ordenen de manera secuencial, 


aunque puedan producirse problemas de secuen- 
ciabilidad, dado que las transacciones pueden leer 
un valor antiguo de algún otro elemento de datos 
y utilizarlo para llevar a cabo una actualización. 

• Las actualizaciones se llevan a cabo en cualquier 
réplica y se propagan a todas las demás. 

Este enfoque puede causar todavía más pro¬ 
blemas, dado que el mismo elemento de datos pue¬ 
de ser actualizado de manera concurrente en varios 
sitios. 

Algunos conflictos debidos a la falta de control de 
la concurrencia distribuida pueden detectarse cuando 
se propagan a otros sitios las actualizaciones (se verá 
el modo en el Apartado 23.5.4), pero la resolución del 
conflicto implica retroceder a las transacciones que 
estén comprometidas y, por tanto, no se garantiza la 
durabilidad de las mismas. Además, puede que se nece¬ 
site intervención del personal encargado para resolver 
los conflictos. Por tanto, los esquemas mencionados 
deben evitarse o utilizarse con precaución. 

19.5.4. Tratamiento de los interbloqueos 

Los algoritmos de prevención y de detección de inter¬ 
bloqueos del Capítulo 16 pueden utilizarse en los siste¬ 
mas distribuidos, siempre que se realicen modificacio¬ 
nes. Por ejemplo, se puede utilizar el protocolo de árbol 
definiendo un árbol global entre los elementos de datos 
del sistema. De manera parecida, el enfoque de orde¬ 
nación por marcas temporales puede aplicarse de mane¬ 
ra directa en entornos distribuidos, como se vio en el 
Apartado 19.5.2. 

La prevención de interbloqueos puede dar lugar a 
esperas y retrocesos innecesarios. Además, puede que 
algunas técnicas de prevención de interbloqueos nece¬ 
siten que se impliquen en la ejecución de una transac¬ 
ción más sitios que los que serían necesarios de otro 
modo. 

Si se permite que los interbloqueos se produzcan y 
se confía en su detección, el problema principal en los 
sistemas distribuidos es la decisión del modo en que se 
mantiene el grafo de espera. Las técnicas habituales para 
tratar este problema exigen que cada sitio guarde un 
grafo local de espera. Los nodos del grafo correspon¬ 
den a todas las transacciones (locales y no locales) que 
en cada momento tienen o solicitan alguno de los ele¬ 
mentos locales de ese sitio. Por ejemplo, la Figura 19.3 
muestra un sistema que consta de dos sitios, cada uno 
de los cuales mantiene su grafo de espera. Obsérvese 
que las transacciones T 2 y T 3 aparecen en los dos gra- 
fos, lo que indica que han solicitado elementos en los 
dos sitios. 

Estos grafos locales de espera se crean de la mane¬ 
ra habitual para las transacciones y los elementos de 
datos locales. Cuando una transacción T¡ en el sitio 5, 
necesita un recurso del sitio S 2 , envía un mensaje de 
solicitud al sitio S 2 . Si el recurso lo tiene la transacción 
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Tj, el sistema introduce un arco Tj Tj en el grafo de 
espera local del sitio S 2 . 

Evidentemente, si algún grafo de espera local tiene 
un ciclo, se ha producido un interbloqueo. Por otro lado, 
el hecho de que no haya ciclos en ninguno de los gra- 
fos locales de espera no significa que no haya interblo¬ 
queos. Para ilustrar este problema considérense los gra- 
fos locales de espera de la Figura 19.3. Cada grafo de 
espera es acíclico y, sin embargo, hay un interbloqueo 
en el sistema debido a que la unión de los grafos loca¬ 
les de espera contiene un ciclo. Este grafo aparece en 
la Figura 19.4. 

En el enfoque de detección centralizada de inter¬ 
bloqueos el sistema crea y mantiene un grafo global 
de espera (la unión de todos los grafos locales) en un 
solo sitio: el coordinador de detección de interbloqueos. 
Dado que hay un retraso en las comunicaciones en el 
sistema hay que distinguir entre dos tipos de grafos de 
espera. Los grafos reales describen el estado real pero 
desconocido del sistema en cualquier momento dado, 
como lo vería un observador omnisciente. Los grafos 
creados son una aproximación generada por el contro¬ 
lador durante la ejecución del algoritmo del controla¬ 
dor. Evidentemente, el controlador debe generar el gra¬ 
fo creado de modo que, siempre que se invoque al 
algoritmo de detección, los resultados mostrados sean 
correctos. Correcto significa en este caso que, si hay 
algún interbloqueo, se comunique con prontitud y, si el 
sistema comunica algún interbloqueo, realmente se halle 
en estado de interbloqueo. 

El grafo global de espera debe poder volver a crear¬ 
se o actualizarse bajo las siguientes condiciones: 

• Siempre que se introduzca o se elimine un nuevo 
arco en alguno de los grafos locales de espera. 

• De manera periódica, cuando se hayan producido 
varias modificaciones en un grafo local de espera. 

• Siempre que el coordinador necesite invocar el 
algoritmo de detección de ciclos. 

Cuando el coordinador invoca el algoritmo de detec¬ 
ción de interbloqueo busca en su grafo global. Si halla 
un ciclo, selecciona una víctima para hacerla retroce¬ 
der. El coordinador debe comunicar a todos los sitios 
que se ha seleccionado como víctima a una transacción 




FIGURA 19.3. Grafos locales de espera. 



FIGURA 19.4. Grafo global de espera de la Figura 19.3. 


concreta. Los sitios, a su vez, hacen retroceder la tran¬ 
sacción víctima. 

Este esquema puede producir retrocesos innecesa¬ 
rios si: 

• Hay ciclos falsos en el grafo global de espera. A modo 
de ejemplo, considérese una instantánea del sistema 
representado por los grafos locales de espera de la 
Figura 19.5. Supóngase que T 2 libera el recurso que 
tiene en el sitio Sj, lo que provoca la eliminación del 
arco 7j —> T 2 en Sj. La transacción T 2 solicita enton¬ 
ces un recurso que tiene Tj en el sitio S 2 , lo que pro¬ 
voca la agregación del arco T 2 —»■ 7j en S 2 . Si el men¬ 
saje Insertar Tj —> 7j de S 2 llega antes que el mensaje 
eliminar Tj —* Tj de Sj, puede que el coordinador des¬ 
cubra el falso ciclo Tj ^ Tj Tj después del men¬ 
saje insertar (pero antes del mensaje eliminar). Pue¬ 
de que se inicie la recuperación de interbloqueo, 
aunque no se haya producido ninguno. 

Obsérvese que la situación con ciclos falsos no 
puede producirse con bloqueos de dos fases. La 
probabilidad de los ciclos falsos suele ser lo bas¬ 
tante baja como para que no cause un problema 
serio de rendimiento. 

• Se produce de verdad un interbloqueo y se esco¬ 
ge una víctima cuando se aborta alguna de las tran- 





FIGURA 19.5. Ciclos falsos en el grafo global de espera. 


476 




















CAPÍTULO 19 BASES DE DATOS DISTRIBUIDAS 


sacciones por motivos no relacionados con inter¬ 
bloqueos. Por ejemplo, supóngase que el sitio Sj 
de la Figura 19.3 decide abortar T 2 . Al mismo tiem¬ 
po, el coordinador ha descubierto un ciclo y ha 
escogido como víctima a T 3 . Tanto T 2 como T 3 se 
hacen retroceder, aunque sólo hiciera falta hacer 
retroceder a T 2 . 


La detección de interbloqueos puede hacerse 
de manera distribuida, con varios sitios que asu¬ 
man partes de la tarea, en lugar de hacerla en un 
solo sitio. No obstante, estos algoritmos resultan 
más complicados y más costosos. Véanse las notas 
bibliográficas para hallar referencias a estos algo¬ 
ritmos 


19.6. DISPONIBILIDAD 


Uno de los objetivos del empleo de bases de datos dis¬ 
tribuidas es la disponibilidad elevada; es decir, la base 
de datos debe funcionar casi todo el tiempo. En con¬ 
creto, dado que los fallos son más probables en los sis¬ 
temas distribuidos de gran tamaño, una base de datos 
distribuida debe seguir funcionando aunque haya varios 
tipos de fallos. La capacidad de continuar funcionando 
incluso durante los fallos se denomina robustez. 

Para que un sistema distribuido sea robusto debe 
detectar los fallos, reconfigurar el sistema de modo que 
el cálculo pueda continuar y recuperarse cuando se repa¬ 
re el procesador o el enlace. 

Los diferentes tipos de fallos se tratan de manera 
diferente. Por ejemplo, la pérdida de mensajes se trata 
mediante su retransmisión. La retransmisión repetida 
de un mensaje por un enlace sin la recepción de un acu¬ 
se de recibo suele ser síntoma de fallo del enlace. La 
red suele intentar hallar una ruta alternativa para el men¬ 
saje. La incapacidad de hallar esa ruta suele ser sínto¬ 
ma de división de la red. 

No obstante, no suele ser posible diferenciar clara¬ 
mente entre los fallos de los sitios y la división de la 
red. El sistema suele poder detectar que se ha produci¬ 
do un fallo, pero puede que no logre identificar el tipo 
de fallo. Por ejemplo, supóngase que el sitio S l no pue¬ 
de comunicar con S 2 . Puede ser que S 2 haya fallado. No 
obstante, otra posibilidad es que el enlace entre S l y S 2 
haya fallado, lo que provoca la división de la red. El 
problema se aborda en parte empleando varios enlaces 
entre los sitios, de modo que aunque falle un enlace los 
sitios sigan conectados. Sin embargo, todavía puede 
producirse un fallo de varios enlaces, por lo que hay 
situaciones en las que no se puede estar seguro de si se 
ha producido un fallo del sitio o una división de la red. 

Supóngase que el sitio Sj ha descubierto que se ha 
producido un fallo. Debe iniciar un procedimiento que 
permita que el sistema se reconfigure y continúe con el 
modo normal de operación. 

• Si en el momento del fallo había transacciones acti¬ 
vas en un sitio que haya fallado o que haya que¬ 
dado inaccesible, esas transacciones se deben abor¬ 
tar. Resulta conveniente abortar con prontitud esas 
transacciones, ya que tienen bloqueos sobre los 
datos en sitios que siguen activos; esperar a que el 
sitio que ha fallado o que ha quedado inaccesible 


vuelva a estar accesible puede impedir otras tran¬ 
sacciones en sitios que están operativos. 

No obstante, en algunos casos, cuando los obje¬ 
tos de datos están replicados, puede que sea posi¬ 
ble seguir con las operaciones de lectura y de actua¬ 
lización aunque algunas réplicas estén inaccesibles. 
En ese caso, cuando se recupera el sitio que ha 
fallado, si tenía réplicas de algún objeto de datos, 
debe obtener los valores actualizados de esos obje¬ 
tos de datos y asegurarse de que recibe todas las 
actualizaciones posteriores. Este problema se abor¬ 
da en el Apartado 19.6.1. 

• Si los datos replicados se guardan en un sitio que 
ha fallado o que está inaccesible, el catálogo debe 
actualizarse para que las consultas no hagan refe¬ 
rencia a la copia ubicada en ese sitio. Cuando un 
sitio vuelve a estar activo hay que asegurarse de 
que los datos que haya en él sean consistentes, 
como se verá en el Apartado 19.6.3. 

• Si un sitio que ha fallado es el servidor central de 
algún subsistema hay que celebrar una elección para 
determinar el nuevo servidor (véase el Apartado 
19.6.5). Entre los servidores centrales están los ser¬ 
vidores de nombres, los coordinadores de concu¬ 
rrencia y los detectores globales de interbloqueo. 

Dado que, en general, no es posible distinguir entre 
los fallos de los enlaces de red y los fallos de los sitios, 
cualquier esquema de reconfiguración debe estar dise¬ 
ñado para funcionar de manera correcta en caso de divi¬ 
sión de la red. En concreto, deben evitarse las situacio¬ 
nes siguientes: 

• Que se elijan dos o más servidores centrales en 
particiones distintas. 

• Que más de una partición actualice un elemento 
de datos replicado. 

19.6.1. Enfoque basado en la mayoría 

El enfoque basado en la mayoría del control distribui¬ 
do de la concurrencia del Apartado 19.5.1.4 puede modi¬ 
ficarse para que funcione a pesar de los fallos. En este 
enfoque, cada objeto de datos guarda con él un núme¬ 
ro de versión para detectar cuándo se produjo la última 
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operación de escritura en él. Siempre que una transac¬ 
ción escribe un objeto también actualiza el número de 
versión de la manera siguiente: 

• Si el objeto de datos a se replica en n sitios dife¬ 
rentes, se debe enviar un mensaje de solicitud de 
bloqueo a más de la mitad de los n sitios en los que 
se guarda a. La transacción no opera sobre a has¬ 
ta que ha conseguido obtener un bloqueo en la 
mayoría de las réplicas de a. 

• Las operaciones de lectura examinan todas las répli¬ 
cas sobre las que se ha obtenido el bloqueo y leen 
el valor de la réplica que tiene el número de versión 
más elevado (de manera opcional también pueden 
escribir este valor en las réplicas con números de 
versión más bajos). Las operaciones de escritura 
leen todas las réplicas igual que hacen las opera¬ 
ciones de lectura para hallar el número de versión 
más elevado (este paso de la transacción normal¬ 
mente lo habrá realizado antes una operación de lec¬ 
tura, y se puede volver a utilizar el resultado). El 
número de versión nuevo es una unidad mayor que 
el número de versión más elevado. La operación de 
escritura escribe en todas las réplicas en las que ha 
obtenido bloqueos y define el nuevo número de ver¬ 
sión como número de versión de todas las réplicas. 

Los fallos durante las transacciones (tanto las divi¬ 
siones de la red como los fallos de los sitios) pueden 
tolerarse siempre que 1) los sitios disponibles en com¬ 
promiso contengan la mayoría de las réplicas de todos 
los objetos en los que hay que escribir y 2) durante las 
operaciones de lectura se lea la mayoría de las réplicas 
para hallar los números de versión. Si se violan estos 
requisitos se debe abortar la transacción. Siempre que 
se satisfagan los requisitos se puede utilizar el protoco¬ 
lo de compromiso de dos fases, como siempre, en los 
sitios que estén disponibles. 

En este esquema la reintegración resulta trivial; no 
hay que hacer nada. Esto se debe a que las operaciones 
de escritura han actualizado la mayoría de las réplicas, 
mientras las operaciones de lectura leen la mayoría de 
las réplicas y hallan como mínimo una que tenga la últi¬ 
ma versión. 

La técnica de numeración de versiones utilizada con 
el protocolo de mayoría también puede utilizarse para 
hacer que funcione el protocolo de consenso de quómm 
en presencia de fallos. Los detalles (evidentes) se dejan 
al lector. No obstante, el riesgo de que los fallos eviten 
que el sistema procese las transacciones aumenta si se 
asignan pesos superiores a algunos sitios. 

19.6.2. Enfoque leer uno, escribir 
todos los disponibles 

Como caso especial de consenso de quorum se puede 
emplear el protocolo sesgado asignando pesos unita¬ 


rios a todos los sitios, definiendo el quorum de lectura 
como 1 y definiendo el quorum de escritura como n 
(todos los sitios). En este caso especial no hace falta 
utilizar números de versión; sin embargo, con que falle 
un solo sitio que contenga un elemento de datos no 
podrá llevarse a cabo ninguna operación de escritura 
en el elemento, dado que no se dispondrá del quorum 
de escritura. Este protocolo se denomina protocolo leer 
uno, escribir todos, ya que hay que escribir todas las 
réplicas. 

Para permitir que continúe el trabajo en caso de fallos 
sería conveniente poder utilizar un protocolo lectura 
de uno, escritura de todos los disponibles. En este 
enfoque las operaciones de lectura se llevan a cabo como 
en el esquema leer uno, escribir todos; se puede leer 
cualquier réplica disponible y se obtienen un bloqueo 
de lectura sobre esa réplica. Se envía una operación de 
escritura a todas las réplicas y se adquieren bloqueos 
de escritura sobre todas las réplicas. Si un sitio no está 
disponible, el gestor de transacciones continúa su labor 
sin esperar a que el sitio se recupere. 

Aunque este enfoque parezca muy atractivo, presenta 
varias complicaciones. En concreto, los fallos de comu¬ 
nicación temporales pueden hacer que un sitio parezca 
no disponible, haciendo que no se lleve a cabo la ope¬ 
ración de escritura pero, cuando el enlace se restaura, 
el sitio no sabe que tiene que llevar a cabo acciones de 
reintegración para ponerse al día con las operaciones 
de escritura que ha perdido. Además, si la red se frag¬ 
menta, puede que cada partición pase a actualizar el mis¬ 
mo elemento de datos, creyendo que los sitios de las 
demás particiones no funcionan. 

El esquema leer uno, escribir todos los disponibles 
puede utilizarse si nunca se producen divisiones de la 
red, pero puede dar lugar a inconsistencias en caso de 
que se produzcan esas fragmentaciones. 

19.6.3. Reintegración de los sitios 

La reintegración al sistema de los sitos o de los enlaces 
reparados exige la adopción de precauciones. Cuando 
se recupera un sitio que ha fallado, debe iniciar un pro¬ 
cedimiento para actualizar sus tablas del sistema para 
que reflejen las modificaciones realizadas mientras esta¬ 
ba fuera de servicio. Si el sitio tiene réplicas de ele¬ 
mentos de datos, debe obtener los valores actualizados 
de esos elementos de datos y asegurarse de que recibe 
todas las actualizaciones que se produzcan a partir de 
entonces. La reintegración de los sitios es más compli¬ 
cada de lo que parece a primera vista, dado que puede 
que haya actualizaciones de los elementos de datos que 
se hayan procesado durante el tiempo en el que el sitio 
se está recuperando. 

Una solución sencilla es detener temporalmente todo 
el sistema hasta que el sitio que ha fallado se vuelva a 
unir a él. En la mayor parte de las aplicaciones, sin 
embargo, esa detención temporal plantea problemas ina¬ 
ceptables. Se han desarrollado técnicas para permitir 
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que los sitios que han fallado se reintegren mientras se 
ejecutan de manera concurrente las actualizaciones de 
los elementos de datos. Antes de que se conceda nin¬ 
gún bloqueo de lectura o de escritura sobre cualquier 
elemento de datos, el sitio debe asegurarse de que se ha 
puesto al día con todas las actualizaciones del elemen¬ 
to de datos. Si se recupera un enlace que había fallado 
se pueden volver a unir dos o más particiones. Dado que 
la división de la red limita las operaciones admisibles 
para algunos de los sitios o para todos ellos, se debe 
informar con prontitud a todos los sitios de la recupe¬ 
ración del enlace. Véanse las notas bibliográficas para 
obtener más información sobre la recuperación en los 
sistemas distribuidos. 

19.6.4. Comparación con la copia 
de seguridad remota 

Los sistemas remotos de copia de seguridad, que se estu¬ 
diaron en el Apartado 17.10, y la réplica en las bases de 
datos distribuidas son dos enfoques alternativos para la 
provisión de una disponibilidad elevada. La diferencia 
principal entre los dos esquemas es que con los siste¬ 
mas remotos de copia de seguridad las acciones como 
el control de la concurrencia y la recuperación se lle¬ 
van a cabo en un único sitio, y sólo se replican en el otro 
sitio los datos y los registros del registro histórico. En 
concreto, los sistemas remotos de copia de seguridad 
ayudan a evitar el compromiso de dos fases, y las sobre¬ 
cargas resultantes. Además, las transacciones sólo tie¬ 
nen que entrar en contacto con un sitio (el sitio princi¬ 
pal) y, así, se evita la sobrecarga de la ejecución del 
código de las transacciones en varios sitios. Por tanto, 
los sistemas remotos de copia de seguridad ofrecen un 
enfoque de la elevada disponibilidad de menor coste 
que la réplica. 

Por otro lado, la réplica puede ofrecer mayor disponi¬ 
bilidad teniendo disponibles varias réplicas y empleando 
el protocolo de mayoría. 

19.6.5. Selección del coordinador 

Varios de los algoritmos que se han presentado exigen 
el empleo de un coordinador. Si el coordinador falla 
debido a un fallo del sitio en el que reside el sistema, 
sólo puede continuar la ejecución reiniciando un nue¬ 
vo coordinador en otro sitio. Un modo de continuar la 
ejecución es el mantenimiento de un coordinador suplen¬ 
te, que esté preparado para asumir la responsabilidad si 
el coordinador falla. 

El coordinador suplente es un sitio que, además de 
otras tareas, mantiene de manera local suficiente infor¬ 
mación como para permitirle asumir el papel de coor¬ 
dinador con un perjuicio mínimo al sistema distribui¬ 
do. Todos los mensajes dirigidos al coordinador los 
reciben tanto el coordinador como su suplente. El coor¬ 
dinador suplente ejecuta los mismos algoritmos y man¬ 
tiene la misma información interna de estado (como, 


por ejemplo, para el coordinador de concurrencia, la 
tabla de bloqueos) que el coordinador auténtico. La úni¬ 
ca diferencia en funcionamiento entre el coordinador y 
su suplente es que el suplente no emprende ninguna 
acción que afecte a otros sitios. Esas acciones se dejan 
al coordinador auténtico. 

En caso de que el coordinador suplente detecte el 
fallo del coordinador auténtico asume el papel de coor¬ 
dinador. Dado que el suplente tiene toda la información 
disponible que tenía el coordinador que ha fallado, el 
procesamiento puede continuar sin interrupción. 

La ventaja principal del enfoque del suplente es la 
capacidad de continuar el procesamiento de manera 
inmediata. Si no hubiera un suplente dispuesto a asu¬ 
mir la responsabilidad del coordinador, el coordinador 
que se designara ex novo tendría que buscar la infor¬ 
mación en todos los sitios del sistema para poder eje¬ 
cutar las tareas de coordinación. Con frecuencia la úni¬ 
ca fuente de parte de la información necesaria es el 
coordinador que ha fallado. En ese caso, puede que sea 
necesario abortar parte de las transacciones activas (o 
todas ellas) y reiniciarlas bajo el control del nuevo coor¬ 
dinador. 

Por tanto, el enfoque del coordinador suplente evita 
el retraso sustancial de la espera mientras el sistema dis¬ 
tribuido se recupera de un fallo del coordinador. El 
inconveniente es la sobrecarga de la ejecución duplica¬ 
da de las tareas del coordinador. Además, el coordi¬ 
nador y su suplente necesitan comunicarse de manera 
regular para asegurarse de que sus actividades están sin¬ 
cronizadas. 

En resumen, el enfoque del coordinador suplente 
supone una sobrecarga durante el procesamiento nor¬ 
mal para permitir una recuperación rápida de los fallos 
del coordinador. 

En ausencia de un coordinador suplente designado, 
o con objeto de tratar varios fallos, los sitios que siguen 
funcionando pueden escoger de manera dinámica un 
nuevo coordinador. Los algoritmos de elección per¬ 
miten que los sitios escojan el sitio del nuevo coordi¬ 
nador de manera descentralizada. Los algoritmos de 
selección necesitan que se asocie un único número de 
identificación con cada sitio activo del sistema. 

El algoritmo luchador para la elección funciona de 
la manera siguiente. Para que la notación y la discusión 
no dejen de ser sencillas, supóngase que el número de 
identificación del sitio S¡ es i y que el coordinador ele¬ 
gido siempre será el sitio activo con el número de iden¬ 
tificación más elevado. Por tanto, cuando un coordina¬ 
dor falla, el algoritmo debe elegir el sitio activo que 
tenga el número de identificación más elevado. El algo¬ 
ritmo debe enviar este número a cada sitio activo del 
sistema. Además, el algoritmo debe proporcionar un 
mecanismo por el que los sitios que se recuperen de un 
fallo puedan identificar al coordinador activo. Supón¬ 
gase que el sitio S¡ envía una solicitud que el coordina¬ 
dor no responde dentro de un intervalo de tiempo pre¬ 
determinado T. En esa situación se supone que el 
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coordinador ha fallado y S¡ intenta elegirse a sí mismo 
como sitio del nuevo coordinador. 

El sitio S¡ envía un mensaje de elección a cada sitio 
que tenga un número de identificación más elevado. 
Luego, el sitio S¡ espera, un intervalo de tiempo T, la 
respuesta de cualquiera de esos sitios. Si no recibe res¬ 
puesta dentro del tiempo T, da por supuesto que todos 
los sitios con números mayores que i han fallado, se eli¬ 
ge a sí mismo sitio del nuevo coordinador y envía un 
mensaje para informar a todos los sitios activos con 
números de identificación menores que i de que es el 
sitio en el que reside el nuevo coordinador. 

Si S¡ recibe una respuesta, comienza un intervalo de 
tiempo 7'para recibir un mensaje que lo informe de que 
se ha elegido a un sitio con un número de identificación 
más elevado (algún otro sitio se está eligiendo coordi¬ 
nador y debe comunicar los resultados dentro del tiem¬ 


po T). Si S¡ no recibe ningún mensaje antes de T ', da 
por supuesto que el sitio con el número más elevado ha 
fallado y Si vuelve a iniciar el algoritmo. 

Después de que se haya recuperado un sitio que ha 
fallado, comienza de inmediato la ejecución de ese 
mismo algoritmo. Si no hay ningún sitio activo con 
un número más elevado, el sitio que se ha recupera¬ 
do obliga a todos los sitios con números más bajos a 
permitirle transformarse en el sitio coordinador, aun¬ 
que ya haya un coordinador activo con un número más 
bajo. Por este motivo, al algoritmo se le denomina 
algoritmo luchador. Si se divide la red, el alogartimo 
luchador elige un coordinador separado en cada par¬ 
tición; para asegurar que se elige a lo sumo un coor¬ 
dinador, los sitios ganadores deberían comprobar adi¬ 
cionalmente que una mayoría de los sitios están en su 
partición. 


19.7. PROCESAMIENTO DISTRIBUIDO DE CONSULTAS 


En el Capítulo 14 se vio que hay gran variedad de méto¬ 
dos para el cálculo de la respuesta a una consulta. Se 
examinaron varias técnicas para escoger una estrategia 
de procesamiento de consultas que minimice la canti¬ 
dad de tiempo que se tarda en calcular la respuesta. Para 
los sistemas centralizados el criterio principal para medir 
el coste de una estrategia dada es el número de accesos 
a disco. En los sistemas distribuidos hay que tener en 
cuenta varios asuntos más, entre los que se incluyen 

• El coste de la transmisión de los datos por la red 

• La ganancia potencial en rendimiento si se hace 
que varios sitios procesen en paralelo partes de la 
consulta 

El coste relativo de la transferencia de los datos por 
la red y de la transferencia de los datos al disco o des¬ 
de él varía ampliamente en función del tipo de red y de 
la velocidad de los discos. Así, en general, no se puede 
centrar exclusivamente en los costes de disco ni en los 
costes de red. Más bien hay que hallar un buen equili¬ 
brio entre los dos. 

19.7.1. Transformación de consultas 

Considérese una consulta extremadamente sencilla: 
«Hallar todas las tupias de la relación cuenta». Aunque 
la consulta es sencilla (en realidad, trivial), su procesa¬ 
miento no es trivial, ya que puede que la relación cuen¬ 
ta esté fragmentada, replicada o ambas cosas, como se 
vio en el Apartado 19.2. Si la relación cuenta está repli¬ 
cada, se tiene que elegir la réplica. Si no se han dividido 
las réplicas, se escoge aquella para la que el coste de 
transmisión es más bajo. No obstante, si se ha dividido 
una réplica, la elección no resulta tan sencilla de hacer. 


dado que hay que calcular varias reuniones o uniones 
para reconstruir la relación cuenta. En ese caso, el núme¬ 
ro de estrategias para el sencillo ejemplo escogido pue¬ 
de ser grande. Puede que la optimización de las consul¬ 
tas mediante la enumeración exhaustiva de todas las 
estrategias alternativas no resulte práctica en esas situa¬ 
ciones. 

La transparencia de la fragmentación implica que los 
usuarios pueden escribir una consulta como 

^nombre-sucursal = «Guadarrama» ( Cuenta ) 

Dado que cuenta está definida como 
cuenta l U cuenta 2 

la expresión que resulta del esquema de traducción de 
nombres es 

^nombre-sucursal = «Guadarrama» {cuenta | U Cuenta 2 ) 

Mediante las técnicas de optimización de consultas del 
Capítulo 13 se puede simplificar de manera automática 
la expresión precedente. El resultado es la expresión 

O nombre-sucursal = «Guadarrama» (dienta |) U 
O nombre-sucursal = «Guadarrama» ( Cuenta 2) 

que incluye dos subexpresiones. La primera sólo impli¬ 
ca a cuenta { y, así, puede evaluarse en el sitio Guada¬ 
rrama. La segunda sólo implica a cuenta 2 y, por tanto, 
puede evaluarse en el sitio Cercedilla. 

Hay otra optimización más que puede hacerse al eva¬ 
luar 

O nombre-sucursal = «Guadarrama» (clienta |) 
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Dado que cuenta { sólo tiene tupias pertenecientes a la 
oficina de Guadarrama, se puede eliminar la operación 
de selección. Al evaluar 

Onombre-sucursal = «Guadarrama» (cuef'ltü 2) 

se puede aplicar la definición del fragmento de cuenta 2 
para obtener 

Onombre-sucursal = «Guadarrama» nombre-sucursal = 

«Cercedilla» {cuenta)) 

Esta expresión es el conjunto vacío, independientemente 
del contenido de la relación cuenta. 

Por tanto, la estrategia final es que el sitio Guada¬ 
rrama devuelva cuenta { como resultado de la consulta. 

19.7.2. Procesamiento de reuniones sencillas 

Como se vio en el Capítulo 13, una decisión importan¬ 
te en la selección de una estrategia de procesamiento de 
consultas es la elección de la estrategia de reunión. Con¬ 
sidérese la siguiente expresión de álgebra relacional: 

cuenta x impositor IX oficina 

Supóngase que ninguna de las tres relaciones está repli¬ 
cada ni fragmentada, y que cuenta está almacenada en 
el sitio Sj, impositor en S 2 y oficina en S 3 . Supóngase 
que S¡ denota el sitio en el que se ha formulado la con¬ 
sulta. El sistema necesita obtener el resultado en el sitio 
S¡. Entre las estrategias posibles para el procesamiento 
de esta consulta figuran las siguientes: 

• Enviar copias de las tres relaciones al sitio S¡. 
Empleando las técnicas del Capítulo 13 hay que 
escoger una estrategia para el procesamiento local 
de toda la consulta en el sitio S¡. 

• Enviar una copia de la relación cuenta al sitio S 2 
y calcular temp l = cuenta X impositor en S 2 . 
Enviar temp l de S 2 a S 3 y calcular temp 2 = temp l 
X oficina en S 3 . Enviar el resultado temp 2 a S 7 . 

• Diseñar estrategias parecidas a la anterior con los 
roles de S lt S 2 y Sj intercambiados. 

Ninguna estrategia es siempre la mejor. Entre los fac¬ 
tores que deben tenerse en cuenta están el volumen de 
los datos que se envían, el coste de la transmisión de los 
bloques de datos entre los pares de sitios y la velocidad 
relativa de procesamiento en cada sitio. Considérense las 
dos primeras estrategias mencionadas. Supóngase que 
los índices presentes de S 2 y Sj sean útiles para calcular 
la reunión. Si se envían las tres relaciones a S¡ se nece¬ 
sitaría recrear estos índices en S¡ o usar una estrategia de 
reunión diferente y posiblemente más costosa. Esta recre¬ 
ación de los índices supone una sobrecarga adicional de 
procesamiento y accesos a disco adicionales. Sin embar¬ 
go, la segunda estrategia tiene el inconveniente de que 
hay que enviar una relación potencialmente larga {cuen¬ 


ta X impositor) de S 2 a S 3 . Esta relación repite los datos 
del nombre de cada cliente una vez por cada cuenta que 
tenga ese cliente. Así, puede que la segunda estrategia 
dé lugar a una transmisión de datos adicional por la red 
en comparación con la primera estrategia. 

19.7.3. Estrategia de semirreunión 

Supóngase que se desea evaluar la expresión r, X r 2 , 
donde r, y r 2 se almacenan en los sitios Sj y S 2 , respec¬ 
tivamente. Sean y R 2 los esquemas de r, y de r 2 . 
Supóngase que se desea obtener el resultado en Sj. Si 
hay muchas tupias de r 2 que no se reúnan con ninguna 
tupia de /q, el envío de r 2 a supone el envío de las 
tupias que no pueden contribuir al resultado. Se desea 
eliminar esas tupias antes de enviar los datos a S y espe¬ 
cialmente si los costes de la red son elevados. 

Una estrategia posible para lograr todo esto es la 
siguiente: 

1. Calcular temp 1 <- II/} n Rl {r¡) en Sj. 

2. Enviar temp l de Sj a Sj. 

3. Calcular temp 2 *—r 2 X temp , en S 2 . 

4. Enviar temp 2 de S 2 a S,. 

5. Calcular r¡ X temp 2 en Sj. La relación resultan¬ 
te es la misma que i\ X r 2 . 

Antes de considerar la eficiencia de esta estrategia hay 
que verificar que la estrategia calcula la respuesta 
correcta. En el paso 3 temp 2 tiene el resultado de r 2 X 
11* p| R2 (/q). En el paso 5 se calcula 

XI r 2 X n S] n/?2 (r,) 

Dado que la reunión es asociativa y conmutativa, se pue¬ 
de volver a escribir esta expresión como 

O'i X Il Ri n R2 (r,)) X r 2 

Dado que r, x II/} n Rl (r,) = /y, la expresión es, real¬ 
mente, igual a /y X r 2 , la expresión que se pretendía 
evaluar. 

Esta estrategia resulta especialmente ventajosa cuan¬ 
do relativamente pocas tupias de r 2 contribuyen a la reu¬ 
nión. Esta situación es probable que se produzca si r, es 
resultado de una expresión de álgebra relacional que 
implique a una selección. En esos casos puede que temp 2 
tenga significativamente menos tupias que r 2 . Los aho¬ 
rros de costes de la estrategia proceden de tener que enviar 
a .Sj sólo temp 2 , en vez de toda r 2 . El envío de temp l a Sj 
supone un coste adicional. Si una fracción de tupias de 
r 2 lo bastante pequeña contribuye a la reunión, la sobre¬ 
carga del envío de temp 1 queda dominada por el ahorro 
de tener que enviar sólo una parte de las tupias de r 2 . 

Esta estrategia se denomina estrategia de semi¬ 
rreunión, del operador de semirreunión del álgebra rela¬ 
cional, denotado por X . La semirreunión de r, con r 2 , 
denotada por r, x r 2 , es 
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n«j O'i x d) 

Por tanto, r { X r 2 selecciona las tupias de r, que han 
contribuido a i\ X r 2 . En el paso 3 temp 2 = r 2 X r,. 

Para las reuniones de varias relaciones esta estrate¬ 
gia puede ampliarse a una serie de pasos de semirreu- 
nión. Se ha desarrollado un importante corpus teórico 
en relación con el empleo de la semirreunión para la 
optimización de consultas. A parte de esta teoría se hace 
referencia en las notas bibliográficas. 

19.7.4. Estrategias de reunión que aprovechan 
el paralelismo 

Considérese una reunión de cuatro relaciones: 

X r 2 XI r 3 X r 4 


donde la relación r¡ se guarda en el sitio S¡. Hay que 
tener en cuenta que el resultado debe presentarse en el 
sitio S { . Hay muchas estrategias posibles para la eva¬ 
luación en paralelo (el problema del procesamiento de 
las consultas en paralelo se estudia con detalle en el 
Capítulo 20). En una de estas estrategias r 1 se envía a 
S 2 y /q X r 2 se calcula en S 2 . Al mismo tiempo, r 3 se 
envía a S 4 y r 3 X r 4 se calcula en S 4 . El sitio S 2 puede 
enviar tupias de (r, x r 2 ) a .S', a medida que se generan, 
en lugar de esperar a que se calcule toda la reunión. De 
manera parecida, S 4 puede enviar tupias de (r 3 x r 4 ) a 
Sj. Una vez que las tupias de (r, X r 2 ) y de (r 3 X r 4 ) 
llegan a S lt puede comenzar el cálculo de (r, x r 2 ) X 
(r 3 X ; 4), con la técnica de reunión canalizada del Apar¬ 
tado 13.7.2.2. Así, el cálculo del resultado de la reunión 
final en A, puede hacerse en paralelo con el cálculo de 
(r, x r 2 ) en S 2 , y con el de (r 3 X r 4 ) en S 4 . 


19.8. BASES DE DATOS DISTRIBUIDAS HETEROGÉNEAS 


Muchas de las últimas aplicaciones de bases de datos 
necesitan datos de gran variedad de bases de datos exis¬ 
tentes previamente y ubicadas en un conjunto hetero¬ 
géneo de entornos de hardware y de software. El trata¬ 
miento de la información ubicada en bases de datos 
distribuidas heterogéneas exige una capa de software 
adicional por encima de los sistemas de bases de datos 
existentes. Esta capa de software se denomina sistema 
de varias bases de datos. Los sistemas locales de bases 
de datos pueden emplear diferentes modelos lógicos y 
varios lenguajes de definición y de tratamiento de datos, 
y puede que se diferencien en sus mecanismos de con¬ 
trol de la concurrencia y de administración de las tran¬ 
sacciones. Los sistemas de varias bases de datos crean 
la ilusión de la integración de las bases de datos lógi¬ 
cas sin exigir la integración física de las bases de datos. 

La integración completa de sistemas heterogéneos 
en una base de datos distribuida homogénea suele resul¬ 
tar difícil o imposible: 

• Dificultades técnicas. La inversión en los progra¬ 
mas de aplicaciones basados en los sistemas de bases 
de datos ya existentes puede ser enorme, y el coste 
de transformar esas aplicaciones puede resultar 
prohibitivo. 

• Dificultades organizativas. Aunque la integra¬ 
ción resulte técnicamente posible, puede que no lo 
sea políticamente, porque los sistemas de bases de 
datos ya existentes pertenezcan a diferentes empre¬ 
sas u organizaciones. En ese caso es importante 
que el sistema de varias bases de datos permita que 
los sistemas de bases de datos locales conserven 
un elevado grado de autonomía para la base de 
datos local y para las transacciones que se ejecu¬ 
ten con esos datos. 


Por estos motivos los sistemas de varias bases de 
datos ofrecen ventajas significativas que compensan su 
sobrecarga. En este apartado se proporciona una intro¬ 
ducción a los retos que se afrontan al construir entor¬ 
nos con varias bases de datos desde el punto de vista de 
la definición de los datos y del procesamiento de las 
consultas. El Apartado 24.6 ofrece una introducción a 
los problemas de la administración de las transacciones 
en varias bases de datos. 

19.8.1. Vista unificada de los datos 

Cada sistema local de administración de bases de datos 
puede utilizar un modelo de datos diferente. Por ejem¬ 
plo, puede que algunos empleen el modelo relacional, 
mientras que otros pueden emplear modelos de datos 
más antiguos, como el modelo de red (véase el Apén¬ 
dice A) o el modelo jerárquico (véase el Apéndice B). 

Dado que se supone que los sistemas con varias bases 
de datos ofrecen la ilusión de un solo sistema de bases 
de datos integrado, hay que utilizar un modelo de datos 
común. Una opción adoptada con frecuencia es el mode¬ 
lo relacional, con SQL como lenguaje común de con¬ 
sulta. En realidad hoy en día hay varios sistemas dispo¬ 
nibles que permiten realizar consultas SQL en sistemas 
de administración de bases de datos no relaciónales. 

Otra dificultad es proporcionar un esquema concep¬ 
tual común. Cada sistema local ofrece su propio esque¬ 
ma conceptual. El sistema de varias bases de datos debe 
integrar estos esquemas independientes en un esquema 
común. La integración de los esquemas es una tarea com¬ 
plicada, sobre todo por la heterogeneidad semántica. 

La integración de los esquemas no es meramente la 
traducción directa de unos lenguajes de definición de 
datos a otros. Puede que los mismos nombres de atri- 
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butos aparezcan en bases de datos locales diferentes 
pero con significados diferentes. Los tipos de datos uti¬ 
lizados en un sistema puede que no estén soportados por 
otros sistemas y puede que la traducción de unos tipos 
a otros no resulte sencilla. Incluso en el caso de tipos de 
datos idénticos pueden surgir problemas debidos a la 
representación física de los datos: Puede que un sistema 
utilice ASCII y otro EBCDIC; las representaciones en 
coma flotante pueden ser diferentes, los enteros pueden 
representarse como ordenación natural de bytes ( big- 
endian) o como ordenación inversa de bytes ( little- 
endian ). En el nivel semántico, el valor entero de una 
longitud pueden ser pulgadas en un sistema y milíme¬ 
tros en otro, lo que crea una situación incómoda en la 
que la igualdad entre los enteros sea sólo una noción 
aproximada (como ocurre siempre con los números con 
coma flotante). Puede que el mismo nombre aparezca en 
lenguajes distintos en los diferentes sistemas. Por ejem¬ 
plo, puede que un sistema basado en los Estados Unidos 
se refiera a la ciudad de Saragossa, mientras que uno con 
base en España se referirá a ella como Zaragoza. 

Todas estas diferencias aparentemente menores deben 
registrarse de manera adecuada en el esquema concep¬ 
tual global común. Hay que proporcionar funciones de 
traducción. Hay que anotar los índices para el compor¬ 
tamiento dependiente del sistema (por ejemplo, el orden 
de clasificación de los caracteres no alfabéticos no es 
igual en ASCII que en EBCDIC). Como ya se ha comen¬ 
tado, la alternativa de convertir cada base de datos a un 
formato común puede que no resulte factible sin dejar 
obsoletas los programas de aplicación ya existentes. 

19.8.2. Procesamiento de las consultas 

El procesamiento de las consultas en las bases de datos 
heterogéneas puede resultar complicado. Algunos de 
los problemas son: 

• Dada una consulta en un esquema global, puede 
que haya que traducir la consulta a consultas en 
los esquemas locales de cada uno de los sitios en 
que hay que ejecutar la consulta. Hay que volver 
a traducir los resultados de las consultas al esque¬ 
ma global. 

La tarea se simplifica escribiendo envolturas 
para cada origen de datos, que ofrecen una vista 
de los datos locales en el esquema global. Las 
envolturas también traducen las consultas del 
esquema global a consultas del esquema local y 
vuelven a traducir los resultados al esquema glo¬ 
bal. Las envolturas puede ofrecerlas cada sitio o 
escribirse de manera independiente como parte 
del sistema de varias bases de datos. 


Las envolturas pueden incluso utilizarse para 
proporcionar una vista relacional de orígenes de 
datos no relaciónales, como las páginas Web (posi¬ 
blemente con interfaces de formularios), archivos 
planos, bases de datos jerárquicas y de red y sis¬ 
temas de directorio. 

• Puede que los orígenes de datos sólo ofrezcan posi¬ 
bilidades de consulta limitadas; por ejemplo, puede 
que soporten las selecciones pero no las reunio¬ 
nes. Puede incluso que restrinjan la forma de las 
selecciones, permitiéndolas sólo para determina¬ 
dos campos; los orígenes de datos Web con inter¬ 
faces de formulario son un ejemplo de estos orí¬ 
genes de datos. Por tanto, puede que haya que 
dividir las consultas para que se lleven a cabo en 
parte en el origen de datos y en parte en el sitio que 
formula la consulta. 

• En general, puede que haya que tener acceso a más 
de un sitio para responder a una consulta dada. 
Puede que haya que procesar las consultas obte¬ 
nidas de los diferentes sitios para eliminar los valo¬ 
res duplicados. Supóngase que un sitio contiene 
las tupias de cuenta que satisfacen las selección 
saldo < 100, mientras que otro contiene las tupias 
de cuenta que satisfacen saldo > 50. Una consul¬ 
ta sobre toda la relación cuenta exigiría tener acce¬ 
so a los dos sitios y eliminar las respuestas dupli¬ 
cadas consecuencia de las tupias con saldo entre 
50 y 100, que están replicadas en los dos sitios. 

• La optimización global de las consultas en bases 
de datos heterogéneas resulta difícil, ya que pue¬ 
de que el sistema de ejecución de consultas conoz¬ 
ca los costes de los planes de consulta alternativos 
en sitios diferentes. La solución habitual es con¬ 
fiar sólo en la optimización a nivel local y utilizar 
únicamente la heurística a nivel global. 

Los sistemas mediadores son sistemas que integran 
varios orígenes de datos heterogéneos, proporcionan 
una vista global integrada de los datos y ofrecen facili¬ 
dades de consulta en el sistema global. A diferencia de 
los sistemas de varias bases de datos completos, los sis¬ 
temas mediadores no se ocupan del procesamiento de 
las transacciones. (Los términos mediador y de varias 
bases de datos suelen utilizarse de manera indistinta, y 
puede que los sistemas denominados mediadores sopor¬ 
ten formas limitadas de las transacciones.) El término 
base de datos virtual se utiliza para hacer referencia a 
los sistemas de varias bases de datos o a los sistemas 
mediadores, ya que ofrecen la apariencia de una sola 
base de datos con un esquema global, aunque los datos 
estén en varios sitios en esquemas locales. 
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19.9. SISTEMAS DE DIRECTORIO 


Considérese una organización que desea poner los 
datos de sus empleados a disposición de diferentes 
miembros de la organización; entre los datos estarían 
el nombre, el cargo, el ID de empleado, la dirección, 
la dirección de correo electrónico, el número de telé¬ 
fono, el número de fax, etcétera. En los días anterio¬ 
res a la informática las organizaciones creaban direc¬ 
torios físicos de los empleados y los distribuían por toda 
la organización. Incluso en nuestros días las compa¬ 
ñías telefónicas crean directorios físicos de sus clientes. 

En general, un directorio es un listado de la infor¬ 
mación sobre algunas clases de objetos como las per¬ 
sonas. Los directorios pueden utilizarse para hallar infor¬ 
mación sobre un objeto concreto o, en sentido contrario, 
hallar objetos que cumplen un determinado requisito. 
En el mundo de los directorios telefónicos físicos los 
directorios que permiten las búsquedas en sentido direc¬ 
to se denominan páginas blancas, mientras que los 
directorios que permiten las búsquedas en sentido inver¬ 
so se denominan páginas amarillas. 

En el mundo interconectado de hoy en día la nece¬ 
sidad de los directorios sigue vigente y, en todo caso, 
es aún más importante. No obstante, hoy en día los direc¬ 
torios deben estar disponibles en las redes informáticas 
en lugar de en forma física (papel). 

19.9.1. Protocolos de acceso a directorios 

La información de directorio puede dejarse disponible 
mediante interfaces Web, como hacen muchas organi¬ 
zaciones y, en especial, las compañías telefónicas. Estas 
interfaces son buenas para las personas que las utilizan. 
Sin embargo, también los programas necesitan tener 
acceso a la información de directorio. Los directorios 
pueden utilizarse para almacenar otros tipos de infor¬ 
mación, de manera parecida a como hacen los directo¬ 
rios del sistema. Por ejemplo, los exploradores Web pue¬ 
den almacenar marcas personales de favoritos y otros 
parámetros del explorador en el sistema de directorios. 
Por tanto, los usuarios pueden tener acceso a los mis¬ 
mos parámetros desde varias ubicaciones, por ejemplo, 
desde casa y desde el trabajo, sin tener que compartir 
un sistema de archivos. 

Se han desarrollado varios protocolos de acceso a 
directorios para ofrecer una manera normalizada de acce¬ 
so a los datos de los directorios. Entre ellos, el más utili¬ 
zado hoy en día es el protocolo de acceso ligero a direc¬ 
torios (Lightweight Directory Access Protocol, LDAP). 

Evidentemente, todos los tipos de datos de los ejem¬ 
plos de este capítulo pueden almacenarse sin demasiados 
problemas en sistemas de bases de datos y se puede tener 
acceso a ellos mediante protocolos como JDBC u ODBC. 
La pregunta, entonces, es el motivo de crear un protoco¬ 
lo especializado para el acceso a la información de direc¬ 
torio. Al menos hay dos respuestas a esta pregunta. 


• En primer lugar, los protocolos de acceso a direc¬ 
torios son protocolos simplificados que atienden a 
un tipo limitado de acceso a los datos. Han evolu¬ 
cionado en paralelo con los protocolos de acceso 
a las bases de datos. 

• En segundo lugar, y lo que es más importante, los 
sistemas de directorio ofrecen un mecanismo sen¬ 
cillo para nombrar a los objetos de manera jerár¬ 
quica, parecida a los nombres de directorios de los 
sistemas de archivos, que pueden utilizarse en un 
sistema distribuido de directorio para especificar la 
información que se almacena en cada servidor de 
directorio. Por ejemplo, puede que un servidor de 
directorio concreto almacene la información de los 
empleados de Laboratorios Bell en Cáceres y que 
otro almacene la información de los empleados de 
Laboratorios Bell en Zarzalejo, lo que da a ambos 
sitios autonomía para controlar sus datos locales. 
Se puede utilizar el protocolo de acceso al directo¬ 
rio para obtener datos de los dos directorios por la 
red. Lo que es más importante, el sistema de direc¬ 
torios puede configurarse para que envíe de mane¬ 
ra automática a un sitio las consultas formuladas 
en el otro, sin intervención del usuario. 

Por estos motivos varias organizaciones tienen sis¬ 
temas de directorios para hacer que la información de 
la organización esté disponible en conexión. Como podía 
esperarse, varias implementaciones de los directorios 
consideran conveniente utilizar las bases de datos rela¬ 
ciónales para almacenar los datos, en lugar de crear sis¬ 
temas de almacenamiento con finalidad especial. 

19.9.2. El protocolo de acceso ligero 

a directorios LDAP (Lightweight 
Directory Access Protocol) 

En general, los sistemas de directorios se implemen- 
tan como uno o varios servidores que atienden a varios 
clientes. Los clientes utilizan la interfaz de progra¬ 
mación de aplicaciones definida por el sistema de 
directorios para comunicarse con los servidores de 
directorios. Los protocolos de acceso a directorios 
también definen un modelo de datos y el control de 
los accesos. 

El protocolo de acceso a directorios X.500, defini¬ 
do por la organización internacional para la normaliza¬ 
ción (International Organization for Standardization, 
ISO), es una norma para el acceso a información de los 
directorios. No obstante, el protocolo es bastante com¬ 
plejo y no se utiliza demasiado. El protocolo de acce¬ 
so ligero a directorios (Lightweight Directory Access 
Protocol, LDAP) ofrece muchas de las características 
de X.500, pero con menos complejidad y se utiliza bas- 
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tante. En el resto de este apartado se esbozarán detalles 
del modelo de datos y del protocolo de acceso de LDAP. 

19.9.2.1. El modelo de datos LDAP 

En LDAP los directorios almacenan entradas, que son 
parecidas a los objetos. Cada entrada debe tener un nom¬ 
bre distinguido (ND), que identifica de manera única 
esa entrada. Los ND, a su vez, está formado por una 
secuencia de nombres distinguidos relativos (NDR). 
Por ejemplo, una entrada puede tener el siguiente nom¬ 
bre distinguido: 

en = Silberschatz, ou = Laboratorios Bell, o = Lucent, 
c = USA 

Como puede verse, el nombre distinguido de este ejem¬ 
plo es una combinación de nombre y dirección (dentro 
de la organización), que comienza por el nombre de la 
persona y luego da la unidad organizativa ( organiza- 
tional unit , ou), organización (organization , o) y país 
( country , c). El orden de los componentes del nombre 
distinguido refleja el orden normal de las direcciones 
postales en lugar del orden inverso que se utiliza al espe¬ 
cificar nombres de caminos para los archivos. El con¬ 
junto de NDR de cada ND viene definido por el esque¬ 
ma del sistema de directorio. 

Las entradas también pueden tener atributos. LDAP 
ofrece los tipos binary (binario), string (cadena de carac¬ 
teres) y time (tiempo) y, de manera adicional, los tipos 
tel (telefónico) para los números de teléfono y Pos- 
talAddress (dirección postal) para las direcciones (las 
líneas se separan con un carácter «$»). A diferencia de 
los del modelo relacional, los atributos de manera pre¬ 
determinada pueden tener varios valores, por lo que es 
posible almacenar varios números de teléfono o direc¬ 
ciones para una sola entrada. 

LDAP permite la definición de clases de objetos con 
nombres y tipos de atributos. Se puede utilizar la heren¬ 
cia para definir las clases de objetos. Además, se pue¬ 
den especificar que las entradas sean de una clase de 
objeto o de varias. No es necesario que haya un única 
clase de objeto más específica a la que pertenezca una 
entrada dada. 

Las entradas se organizan en un árbol de informa¬ 
ción del directorio (AID), de acuerdo con sus nombres 
distinguidos. Las entradas en el nivel de las hojas del 
árbol suelen representar objetos concretos. Las entra¬ 
das que son nodos internos representan objetos como 
las unidades organizativas, las organizaciones o los paí¬ 
ses. Los hijos de cada nodo tienen un ND que contiene 
todos los NDR del padre, más uno o varios NDR adi¬ 
cionales. Por ejemplo, puede que un nodo interno ten¬ 
ga c=España, y todas las entradas por debajo de él ten¬ 
gan el valor España para el NDR c. 

No hace falta almacenar el nombre distinguido com¬ 
pleto en una entrada. El sistema puede generar el nom¬ 
bre distinguido de cada entrada recorriendo el AID en 
sentido ascendente desde la entrada, reuniendo los com¬ 


ponentes NDR=valor para crear el nombre distinguido 
completo. 

Puede que las entradas tengan más de un nombre dis¬ 
tinguido (por ejemplo, la entrada de una persona en más 
de una organización). Para tratar estos casos el nivel de 
las hojas del AID puede ser un alias, que apunte a una 
entrada en otra rama del árbol. 

19.9.2.2. Tratamiento de los datos 

A diferencia de SQL, LDAP no define ni un lenguaje 
de definición de datos ni un lenguaje de tratamiento de 
datos. Sin embargo, LDAP define un protocolo de red 
para llevar a cabo la definición y el tratamiento de los 
datos. Los usuarios de LDAP pueden utilizar una inter¬ 
faz de programación de aplicaciones o las herramien¬ 
tas ofrecidas por varios fabricantes para llevar a cabo 
la definición y el tratamiento de los datos. LDAP tam¬ 
bién define un formato de archivos denominado for¬ 
mato de intercambio de datos LDAP (LDAP Data 
Interchange Format, LDIF) que puede utilizarse para 
almacenar e intercambiar información. 

El mecanismo de consulta en LDAP es muy senci¬ 
llo, consiste simplemente en selecciones y proyeccio¬ 
nes, sin ninguna reunión. Cada consulta debe especifi¬ 
car lo siguiente: 

• Una base (es decir, un nodo del AID) dando su 
nombre distinguido (el camino desde la raíz hasta 
el nodo). 

• Una condición de búsqueda, que puede ser una 
combinación booleana de condiciones para dife¬ 
rentes atributos. Se soportan la igualdad, la coin¬ 
cidencia con caracteres comodín y la igualdad 
aproximada (la definición exacta de igualdad apro¬ 
ximada depende del sistema). 

• Un ámbito, que puede ser sencillamente la base, 
la base y sus hijos o todo el subárbol por debajo 
de la base. 

• Los atributos que hay que devolver. 

• Los límites al número de resultados y al consumo 
de recursos. 

La consulta también puede especificar si hay que eli¬ 
minar de manera automática las referencias de los alias; 
si se desactivan las eliminaciones de referencias de los 
alias se pueden devolver las entradas de los alias como 
respuestas. 

Una manera de consultar orígenes de datos LDAP 
es emplear los URL LDAP. Ejemplos de los URL LDAP 
son: 

ldap:://aura.research.bell-labs.com/o=Lucent,c=USA 
ldap:://aura research.bell-labs.com/o=Lucent,c=USA 
??sub?cn=Korth. 

El primer URL devuelve todos los atributos de todas las 
entradas del servidor en que la organización es Lucent y 
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el país es EEUU. El segundo URL ejecuta una consulta 
de búsqueda (selección) cn=Korth en el subárbol del nodo 
con el nombre distinguido o=Lucent, c=USA. Los signos 
de interrogación de la URL separan campos diferentes. 
El primer campo es el nombre distinguido, en este caso 
o=Lucent,c=USA. El segundo campo, la lista de atribu¬ 
tos que hay que devolver, se ha dejado vacía, lo que sig¬ 
nifica que hay que devolver todos los atributos. El tercer 
atributo, sub, indica que hay que buscar en todo el subár¬ 
bol. El último parámetro es la condición de búsqueda. 

Una segunda manera de consultar un directorio 
LDAP es utilizar una interfaz de programación de apli¬ 
caciones. La Figura 19.6 muestra un fragmento de códi¬ 
go C que se utiliza para conectarse con servidores LDAP 
y ejecutar una consulta en el servidor. El código en pri¬ 
mer lugar abre una conexión con un servidor LDAP 
mediante Idap open y Idap bind. Luego ejecuta una con¬ 
sulta mediante Idap search s. Los argumentos para Idap 
search s son el controlador de conexión LDAP, el ND 
de la base desde la que se debe realizar la búsqueda, el 
ámbito de la búsqueda, la condición de búsqueda, la lis¬ 
ta de atributos que hay que devolver y un atributo deno¬ 
minado attrsonly que, si se le asigna el valor de 1, hace 
que sólo se devuelva el esquema del resultado, sin nin¬ 
guna tupia real. El último argumento es un argumento 
de resultados que devuelve el resultado de la búsqueda 
en forma de estructura LDAPMessage. 


El primer bucle for itera sobre cada entrada del resul¬ 
tado y la imprime. Obsérvese que cada entrada puede 
tener varios atributos, y el segundo bucle for imprime 
cada uno de los atributos. Dado que los atributos en 
LDAP pueden tener varios valores, el tercer bucle for 
imprime cada valor de cada atributo. Las llamadas Idap 
msgfree y Idap valué free liberan la memoria que asig¬ 
nan las bibliotecas LDAP. La Figura 19.6 no muestra el 
código para tratar las condiciones de error. 

La API LDAP también contiene funciones para crear, 
actualizar y eliminar entradas, así como para otras ope¬ 
raciones con el AID. Cada llamada a una función se com¬ 
porta como una transacción independiente; LDAP no 
soporta la atomicidad de las actualizaciones múltiples. 

19.9.2.3. Árboles distribuidos de directorio 

La información sobre las organizaciones puede hallarse 
dividida entre varios AIDs, cada uno de los cuales alma¬ 
cena información sobre algunas entradas. El sufijo de 
los AIDs es una secuencia de pares RDN=valores (RDN, 
Relative Distinguished Ñame, nombre relativo distingui¬ 
do) que identifica la información que almacena cada AID; 
los pares están concatenados con el resto del nombre dis¬ 
tinguido generado recorriendo el árbol desde la entrada 
hasta la raíz. Por ejemplo, el sufijo de un AID puede ser 
o=Fundent, c=España, mientras que otro puede tener el 


#¡nclude <stdio.h> 

#¡nclude <ldap.h> 
main() { LDAP *ld; 

LDAPMessage *res, *entry; 

char *dn, *attr, *attrList[] = {“telephoneNumber”, NULL¡; 

BerElement *ptr; 
int vals, i; 

Id = ldap_open(“aura. research.bell-labs.com”, LDAP PORT); 

Idap simple bind(ld, “avi”, “avl-passwd”); 

Idap search s(ld, “o=Lucent, c=USA”, LDAP SCOPE SUBTREE, “cn=Korth”, 
attrList, /‘attrsonly*/ O, &res); 

pr¡ntf(“Se han encontrado %d entradas”, ldap_count„entries(ld, res)); 
for (entry=ldap_first_entry(ld, res); entry != NULL; 

entry = ldap_next_entry(ld, entry)) 

{ 

dn = ldap_get_dn(ld, entry); 
printf(“Nombre distinguido: %s”, dn); 

Idap memfree(dn); 

for (attr = ldap_first_attribute(ld, entry, &ptr); 
attr! NULL; 

attr = ldap_next_attribute(ld, entry, ptr)) 

( 

printf(“%s: ”, attr); 

vals = ldap_get_values(ld, entry, attr); 
for (i=0; vals[¡] != NULL; i++) 
printf(“%s, ”, vals[i]); 

Idap valué free(vals); 


ldap„msgfree(res); 

ldap_unbind(ld); 


FIGURA 19.6. Ejemplo de código LDAP en C. 


486 


CAPÍTULO 19 BASES DE DATOS DISTRIBUIDAS 


sufijo o=Fundent, c=Chile. Los AIDs pueden estar sepa¬ 
rados por organizaciones y por criterios geográficos. 

Los nodos de un AID pueden contener una referencia 
a un nodo de otro AID; por ejemplo, la unidad organiza¬ 
tiva Laboratorios Bell bajo o=Fundent, c=España puede 
tener su propio AID, en cuyo caso el AID de o=Fundent, 
c=España tendría el nodo ou=Laboratorios Bell que repre¬ 
sentará una referencia al AID de Laboratorios Bell. 

Las referencias son el componente clave que ayuda 
a organizar un conjunto distribuido de directorios en un 
sistema integrado. Cuando un servidor recibe una con¬ 
sulta sobre un AID, puede que devuelva una referencia 
al cliente, el cual a su vez emite una consulta sobre el 
AID referenciado. El acceso al AID referenciado es 
transparente, sin el conocimiento del usuario. Alterna¬ 
tivamente, el propio servidor puede emitir la consulta 
al AID referenciado y devolver los resultados con los 
resultados calculados localmente. 


El mecanismo de denominación jerárquico utiliza¬ 
do por LDAP ayuda a repartir el control de la informa¬ 
ción entre diferentes partes de la organización. La faci¬ 
lidad de las referencias ayuda a integrar todos los 
directorios de una organización en un solo directorio 
virtual. 

Aunque no sea un requisito LDAP, las organizacio¬ 
nes suelen escoger repartir la información por criterios 
geográficos (por ejemplo, una organización puede man¬ 
tener un directorio por cada sitio en que tenga una pre¬ 
sencia importante) o según la estructura organizativa 
(por ejemplo, cada unidad organizativa, como puede ser 
un departamento, mantiene su propio directorio). 

Muchas implementaciones de LDAP soportan la 
réplica maestro-esclavo y la réplica multimaestro de los 
AIDs, aunque la réplica no forme parte de la versión 
actual de la norma LDAP, la 3. El trabajo de normali¬ 
zación de la réplica en LDAP se halla en curso. 


19.10. RESUMEN 


• Los sistemas distribuidos de bases de datos consisten 
en un conjunto de sitios, cada uno de los cuales man¬ 
tiene un sistema local de bases de datos. Cada sitio 
puede procesar las transacciones locales: las transac¬ 
ciones que sólo tienen acceso a datos de ese sitio. 
Además, cada sitio puede participar en la ejecución 
de transacciones globales, las transacciones que tie¬ 
nen acceso a los datos de varios sitios. La ejecución 
de las transacciones globales necesita que haya comu¬ 
nicación entre los sitios. 

• Las bases de datos distribuidas pueden ser homogé¬ 
neas, en las que todos los sitios tienen un esquema y 
un código de sistemas de bases de datos comunes, o 
heterogéneas, en las que los esquemas y los códigos 
de los sistemas pueden ser diferentes. 

• Hay varios problemas relacionados con el almacena¬ 
miento en relación con las bases de datos distribui¬ 
das, incluidas la réplica y la fragmentación. Resulta 
esencial que el sistema minimice el grado en el que 
los usuarios deben conocer el modo en que se alma¬ 
cenan las relaciones. 

• Los sistemas distribuidos pueden sufrir los mismos 
tipos de fallos que los sistemas centralizados. No obs¬ 
tante, hay fallos adicionales con los que hay que tra¬ 
tar en los entornos distribuidos, entre ellos, el fallo de 
un sitio, el fallo de un enlace, la pérdida de un men¬ 
saje y la división de la red. Cada uno de estos pro¬ 
blemas hay que considerarlo en el diseño del esque¬ 
ma distribuido de recuperación. 

• Para asegurar la atomicidad todos los sitios en los que 
se ejecuta la transacción T deben estar de acuerdo en 
el resultado final de su ejecución. O bien T se com¬ 
promete en todos los sitios o se aborta en todos los 


sitios. Para asegurar esta propiedad el coordinador de 
la transacción de T debe ejecutar un protocolo de com¬ 
promiso. El protocolo de compromiso más utilizado 
es el protocolo de compromiso de dos fases. 

• El protocolo de compromiso de dos fases puede con¬ 
ducir a bloqueos, la situación en que el destino de una 
transacción no puede determinarse hasta que se recu¬ 
pere un sitio que ha fallado (el coordinador). Se pue¬ 
de utilizar el protocolo de compromiso de tres fases 
para reducir la probabilidad de bloqueo. 

• La mensajería persistente ofrece un modelo alterna¬ 
tivo para el tratamiento de las transacciones distri¬ 
buidas. El modelo divide cada transacción en varias 
partes que se ejecutan en bases de datos diferentes. 
Los mensajes persistentes (que está garantizado que 
se entregan exactamente una vez, independientemente 
de los fallos) se envían a los sitios remotos para soli¬ 
citar que se emprendan acciones en ellos. Aunque la 
mensajería persistente evita el problema de los blo¬ 
queos, los desarrolladores de aplicaciones tienen que 
escribir código para tratar varios tipos de fallos. 

• Los diferentes esquemas de control de la concurren¬ 
cia empleados en los sistemas centralizados pueden 
modificarse para su empleo en entornos distribuidos. 

— En el caso de los protocolos de bloqueo, el único 
cambio que hay que añadir es el modo en que se 
implementa el gestor de bloqueos. Hay varios 
enfoques posibles. Se pueden utilizar uno o varios 
coordinadores centrales. Si, en vez de eso, se adop¬ 
ta un enfoque con un gestor distribuido de blo¬ 
queos, hay que tratar de manera especial los datos 
replicados. 
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— Entre los protocolos para el tratamiento de los 
datos replicados se hallan el protocolo de copia 
principal, el de mayoría, el sesgado y el de con¬ 
senso de quorum. Cada uno de ellos tiene dife¬ 
rentes equilibrios en términos de coste y de capa¬ 
cidad de trabajar en presencia de fallos. 

— En el caso de los esquemas de marcas tempora¬ 
les y de validación, el único cambio necesario es 
el desarrollo de un mecanismo para la generación 
de marcas temporales globales únicas. 

— Muchos sistemas de bases de datos soportan la 
réplica perezosa, en la que las actualizaciones se 
propagan a las réplicas ubicadas fuera del ámbi¬ 
to de la transacción que llevó a cabo la actualiza¬ 
ción. Estas facilidades deben utilizarse con gran¬ 
des precauciones, ya que pueden dar lugar a 
ejecuciones no secuenciables. 

• La detección de interbloqueos en entornos con ges¬ 
tor distribuido de bloqueos exige la colaboración entre 
varios sitios, dado que puede haber interbloqueos glo¬ 
bales aunque no haya interbloqueos locales. 

• Para ofrecer una elevada disponibilidad, las bases de 
datos distribuidas deben detectar los fallos, reconfi¬ 
gurarse de modo que pueda continuar el cálculo y 
recuperarse cuando se repare el procesador o el enla¬ 
ce. La tarea se complica enormemente por el hecho 
de que resulta difícil distinguir entre la división de la 
red y los fallos de los sitios. 

Se puede extender el protocolo de mayoría utili¬ 
zando números de versiones para permitir que con¬ 
tinúe el procesamiento de las transacciones incluso 
en presencia de fallos. Aunque el protocolo supone 
una sobrecarga significativa, funciona independien¬ 
temente del tipo de fallo. Se dispone de protocolos 
menos costosos para tratar los fallos de los sitios, 
pero dan por supuesto que no se producen divisiones 
de la red. 

• Algunos algoritmos distribuidos exigen el empleo de 
coordinadores. Para ofrecer una elevada disponibili¬ 
dad el sistema debe mantener una copia de seguridad 
que esté preparada para asumir la responsabilidad si 


falla el coordinador. Otro enfoque es escoger el nue¬ 
vo coordinador después de que haya fallado el coor¬ 
dinador. Los algoritmos que determinan el sitio que 
deberá actuar como coordinador se denominan algo¬ 
ritmos de elección. 

• Puede que las consultas a las bases de datos distri¬ 
buidas necesiten tener acceso a varios sitios. Se dis¬ 
pone de varias técnicas de optimización para escoger 
los sitios a los que hay que tener acceso. Basadas en 
la fragmentación y en la réplica, las técnicas pueden 
utilizar técnicas de semirreunión para reducir la trans¬ 
ferencia de datos. 

• Las bases de datos distribuidas heterogéneas permi¬ 
ten que cada sitio tenga sus propios esquemas y códi¬ 
go de sistema de bases de datos. Los sistemas de 
varias bases de datos ofrecen un entorno en el que 
las nuevas aplicaciones de bases de datos pueden 
tener acceso a los datos de varias bases de datos ya 
existentes ubicadas en diferentes entornos de hard¬ 
ware y de software heterogéneos. Puede que los sis¬ 
temas locales de bases de datos empleen modelos 
lógicos y lenguajes de definición o de manipulación 
de datos diferentes y puede que se diferencien en los 
mecanismos de control de la concurrencia o de admi¬ 
nistración de las transacciones. Los sistemas de 
varias bases de datos crean la ilusión de la integra¬ 
ción lógica de las bases de datos, sin exigir la inte¬ 
gración física. 

• Los sistemas de directorio pueden considerarse una 
modalidad especializada de base de datos en la que 
la información se organiza de manera jerárquica pare¬ 
cida al modo en que los archivos se organizan en los 
sistemas de archivos. Se tiene acceso a los directorios 
mediante protocolos normalizados de acceso a direc¬ 
torios como LDAP. 

Los directorios pueden distribuirse entre varios 
sitios para proporcionar autonomía a cada sitio. Los 
directorios pueden contener referencias a otros direc¬ 
torios, lo que ayuda a crear vistas integradas en que 
cada consulta sólo se envía a un directorio y se eje¬ 
cuta de manera transparente en los directorios corres¬ 
pondientes. 


TÉRMINOS DE REPASO 


• Algoritmo luchador 

• Algoritmos de selección 

• Alias 

• Arboles distribuidos de directorio 

• Autonomía 

• Base de datos distribuida heterogénea 

• Base de datos distribuida homogénea 


• Base de datos virtual 

• Control de la concurrencia 

• Coordinador suplente 

• Coordinador de transacciones 

• Copia principal 

• Disponibilidad 

• División de la red 
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• Estrategia de semirreunión 

• Fragmentación de los datos 

— Fragmentación horizontal 

— Fragmentación vertical 

• Gestor distribuido de bloqueos 

• Gestor único de bloqueos 

• Gestor de transacciones 

• Instantánea consistente con las transacciones 

• Marcas temporales 

• Mediadores 

• Mensajería persistente 

• Modalidades de fallo del sistema 

• Procesamiento distribuido de consultas 

• Propagación perezosa 

• Protocolo de acceso ligero a directorios FDAP (Fight- 
weight directory access protocol) 

— Árbol de información del directorio (AID) 

— Nombre distinguido (ND) 

— Nombres distinguidos relativos (NDR) 

• Protocolo de compromiso de dos fases (C2F) 

— Estado de preparación 

— Problema del bloqueo 

— Transacciones dudosas 

• Protocolo de compromiso de tres fases (C3F) 

• Protocolos de compromiso 

• Protocolos para las réplicas 

— Copia principal 

— Protocolo de consenso de quorum 


— Protocolo de mayoría 

— Protocolo sesgado 
Referencia 
Réplica de datos 
Réplica maestro-esclavo 

Réplica con varios maestros (actualización distribuida) 
Robustez 

— Enfoque basado en la mayoría 

— Feer uno, escribir todo 

— Feer uno, escribir todos los disponibles 

— Reintegración de sitios 
Selección del coordinador 
Servidor de nombres 

Sistema de varias bases de datos 
Sistemas de directorio 
Sufijo AID 

Transacciones distribuidas 

— Transacciones globales 

— Transacciones locales 

Transparencia de los datos 

— Transparencia de la fragmentación 

— Transparencia de la réplica 

— Transparencia de la ubicación 
Tratamiento de los interbloqueos 

— Ciclos falsos 

— Grafo global de espera 

— Grafo local de espera 
Referencia 


EJERCICIOS 


19.1 Discútanse las ventajas relativas de las bases de datos 
centralizadas y de las distribuidas. 

19.2 Expliqúense las diferencias entre transparencia de la 
fragmentación, transparencia de las réplicas y transpa¬ 
rencia de la ubicación. 

19.3 Indíquese lo que diferencia a una base de datos distri¬ 
buida diseñada para una red de área local de otra dise¬ 
ñada para una red de área amplia. 

19.4 Indíquese en qué momento resulta útil tener réplicas de 
los datos o tenerlos fragmentados. Expliqúese la respuesta. 

19.5 Expliqúense los conceptos de transparencia y de autono¬ 
mía. Indíquese el motivo de que estos conceptos sean de¬ 
seables desde el punto de vista de los factores humanos. 

19.6 Para crear un sistema distribuido con elevada disponi¬ 
bilidad hay que conocer los tipos de fallos que pueden 
producirse. 


a. Indíquense los tipos de fallos posibles en los siste¬ 
mas distribuidos. 

b. Indíquense los elementos de la lista de la pregunta 
a que también sean aplicables a un sistema centra¬ 
lizado. 

19.7 Considérese un fallo que se produce durante la eje¬ 
cución de C2F para una transacción. Para cada fallo 
posible de los indicados en el Ejercicio 19.6.a expli¬ 
qúese el modo en que C2F asegura la atomicidad de 
la transacción a pesar del fallo. 

19.8 Considérese un sistema distribuido con dos sitios, A y 
B. Indíquese si el sitio A puede distinguir entre: 

• B deja de funcionar. 

• El enlace entre Ay B deja de funcionar. 

• B está extremadamente sobrecargado y su tiempo 
de respuesta es cien veces el habitual. 
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Indíquense las implicaciones de la respuesta para la 
recuperación de los sistemas distribuidas. 

19.9 El esquema de mensajería persistente descrito en este 
capítulo depende de las marcas temporales combina¬ 
das con el desecho de los mensajes recibidos si son 
demasiado antiguos. Propóngase un esquema alterna¬ 
tivo basado en los números de secuencia en lugar de 
las marcas temporales. 

19.10 Dese un ejemplo en que el enfoque de leer uno, escri¬ 
bir todos los disponibles conduzca a un estado erró¬ 
neo. 

19.11 Si se aplica una versión distribuida del protocolo de 
granularidad múltiple del Capítulo 16 a una base de 
datos distribuida, el sitio responsable del DAG puede 
convertirse en un cuello de botella. Supóngase que se 
modifica ese protocolo de la manera siguiente: 

• Sólo se permiten en la raíz bloqueos en modo ten¬ 
tativo. 

• A todas las transacciones se les conceden de mane¬ 
ra automática todos los bloqueos en modo tentativo 
posibles. 

Muéstrese que estas modificaciones alivian el proble¬ 
ma sin permitir planificaciones no secuenciables. 

19.12 Expliqúese la diferencia entre la réplica de datos en 
los sistemas distribuidos y el mantenimiento de sitios 
remotos de respaldo. 

19.13 Dese un ejemplo en el que la réplica perezosa pueda 
conducir a un estado inconsistente de la base de datos, 
aunque las actualizaciones obtengan un bloqueo exclu¬ 
sivo sobre la copia principal (maestra). 

19.14 Estudíense y resúmanse las facilidades que el siste¬ 
ma de bases de datos que se está utilizando ofrece 
para tratar los estados inconsistentes que pueden 
alcanzarse con la propagación perezosa de las actua¬ 
lizaciones. 

19.15 Discútanse las ventajas e inconvenientes de los dos 
métodos presentados en el Apartado 19.5.2 para 
la generación de marcas temporales únicas global¬ 
mente. 

19.16 Considérese el siguiente algoritmo de detección de 
interbloqueo. Cuando la transacción 7 j, en el sitio 
S lt solicita un recurso a T¡, en el sitio S 3 , se envía un 
mensaje de solicitud con la marca temporal n. Se 
inserta el arco (T¡, T¡, n) en el grafo local de espera 
de 5V El arco (T¡, T¡, n) sólo se inserta en el grafo 
local de espera de S 3 si T¡ ha recibido el mensaje de 
solicitud y no se puede conceder de manera inme¬ 
diata el recurso solicitado. La solicitud de T¡ a T¡ en 
el mismo sitio se trata de la manera habitual; no se 
asocia ninguna marca temporal con el arco (T¡, T). 
El coordinador central invoca el algoritmo de detec¬ 
ción enviando el mensaje de inicio a cada sitio del 
sistema. 

Al recibir este mensaje, cada sitio envía al coordi¬ 
nador su grafo local de espera. Obsérvese que ese gra¬ 
fo contiene toda la información local que el sitio tie¬ 
ne sobre el estado del grafo real. El grafo de espera 
refleja un estado instantáneo del sitio, pero no está sin¬ 
cronizado con respecto a ningún otro sitio. 


Cuando el controlador ha recibido una contestación 
de cada sitio crea un grafo de la manera siguiente: 

• El grafo contiene un vértice para cada transacción 
del sistema. 

• El grafo tiene un arco (T¡, T) si y sólo si 

— Hay un arco (T¡, T¡) en uno de los grafos de es¬ 
pera. 

— Aparece un arco (T¡, Ti, n) (para algún ri) en más 
de un grafo de espera. 

Pruébese que, si hay un ciclo en el grafo creado, el sis¬ 
tema se halla en estado de interbloqueo y que, si no 
hay ningún ciclo en el grafo creado, el sistema no se 
hallaba en estado de interbloqueo cuando comenzó la 
ejecución del algoritmo. 

19.17 Considérese una relación que está fragmentada hori¬ 
zontalmente por número-planta : 

empleado ( nombre, dirección, sueldo, 
número-planta ) 

Supóngase que cada fragmento tiene dos réplicas: Una 
almacenada en el sitio de Madrid y otra almacenada 
localmente en el sitio de la planta. Descríbase una bue¬ 
na estrategia de procesamiento de las consultas siguien¬ 
tes formuladas en el sitio de Lima. 

a. Hallar todos los empleados de la planta de Managua. 

b. Hallar el sueldo promedio de todos los empleados. 

c. Hallar el empleado mejor pagado de cada uno de 
los sitios siguientes: Buenos Aires, Rosario, Cór¬ 
doba, Bahía Blanca. 

d. Hallar el empleado peor pagado de la compañía. 

19.18 Considérense las relaciones 

empleado ( nombre, dirección, sueldo, 
número-planta ) 

máquina (número-máquina, tipo, 
número-planta ) 

Supóngase que la relación empleado está fragmenta¬ 
da horizontalmente por número-planta y que cada frag¬ 
mento se almacena localmente en el sitio de su plan¬ 
ta correspondiente. Supóngase que la relación máquina 
se almacena entera en el sitio de Sucre. Descríbase una 
buena estrategia para el procesamiento de cada una de 
las consultas siguientes. 

a. Hallar todos los empleados de la planta que con¬ 
tiene el número de máquina 1130. 

b. Hallar todos los empleados de las plantas que con¬ 
tienen máquinas cuyo tipo sea «trituradora». 

c. Hallar todas las máquinas de la planta de Almadén. 

d. Hallar empleado M máquina. 

19.19 Para cada una de las estrategias del Ejercicio 19.18 
indíquese el modo en que la elección de la estrategia 
depende: 

a. Del sitio en el que se formuló la consulta 

b. Del sitio en el que se desea obtener el resultado 

19.20 Calcúlese r X s para las relaciones de la Figura 19.7. 
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FIGURA 19.7. Relaciones para el Ejercicio 19.20. 


19.21 ¿Es necesariamente r¡ X r¡ igual a r¡ X rp ¿En qué 
circunstancias es cierto que r¡ X r¡ = r¡ X rp 

19.22 Dado que la funcionalidad LDAP puede implemen- 
tarse sobre un sistema de bases de datos, indíquese la 
necesidad de la norma LDAP. 

19.23 Descríbase el modo en que se puede utilizar LDAP 
para ofrecer varias vistas jerárquicas de los datos sin 
replicar los datos del nivel básico. 
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CAPÍTULO 



BASES DE DATOS PARALELAS 


E n este capítulo se estudian los algoritmos fundamentales utilizados en los sistemas 
paralelos de bases de datos basados en el modelo de datos relacional. En concreto, este 
capítulo se centra en la ubicación de los datos en varios discos y en la evaluación en 
paralelo de las operaciones relaciónales, que han sido esenciales para el éxito de las bases de 
datos paralelas. 


20.1. INTRODUCCIÓN 


Hace quince años, los sistemas paralelos de bases de 
datos han estado casi descartados incluso por algunos 
de sus más firmes defensores. Actualmente están comer¬ 
cializados con éxito por prácticamente todos las fabri¬ 
cantes de bases de datos. Este cambio lo han impulsa¬ 
do las siguientes tendencias: 

• Los requisitos transaccionales de las empresas han 
aumentado con el uso creciente de las computado¬ 
ras. Además, el crecimiento de World Wide Web 
ha creado muchos sitios con millones de visitan¬ 
tes, y las cantidades crecientes de los datos recogi¬ 
dos por los visitantes han producido bases de datos 
extremadamente grandes en muchas empresas. 

• Las empresas utilizan volúmenes crecientes de 
datos —como los detalles sobre lo que compran 
las personas, los vínculos que pulsan o la hora a la 
que realiza las llamadas telefónicas— para plani¬ 
ficar sus actividades y sus tarifas. Las consultas 
utilizadas para estos fines se denominan consultas 
de ayuda a la toma de decisiones y las necesida¬ 
des de datos para las mismas pueden llegar a los 
terabytes. Los sistemas con un único procesador 
no son capaces de tratar volúmenes de datos tan 
grandes a la velocidad necesaria. 

• La naturaleza orientada a conjuntos de las consul¬ 
tas de bases de datos se presta de modo natural a 
la paralelización. Varios sistemas comerciales y de 


investigación han demostrado la potencia y dimen- 
sionabilidad del procesamiento paralelo de con¬ 
sultas. 

• Al abaratarse los microprocesadores, las máqui¬ 
nas paralelas se han vuelto comunes y relativa¬ 
mente baratas. 

Como se ha discutido en el Capítulo 18, el parale¬ 
lismo se utiliza para proporcionar aceleración, y las con¬ 
sultas se ejecutan más rápido debido a que se propor¬ 
cionan más recursos, como procesadores y discos. El 
paralelismo también se utiliza para proporcionar amplia- 
bilidad, y las cargas de trabajo crecientes se tratan sin 
aumentar el tiempo de respuesta mediante un aumento 
en el grado de paralelismo. 

En el Capítulo 18 se esbozaron las diferentes arqui¬ 
tecturas de los sistemas paralelos de bases de datos: de 
memoria compartida, de discos compartidos, sin com¬ 
partimiento y las arquitecturas jerárquicas. En resumen, 
en las arquitecturas de memoria compartida todos los 
procesadores comparten memoria y discos; en las arqui¬ 
tecturas de disco compartido los procesadores tienen 
memorias independientes pero comparten los discos; en 
las arquitecturas sin compartimiento los procesadores 
no comparten ni la memoria ni los discos; y las arqui¬ 
tecturas jerárquicas tienen nodos que no comparten entre 
sí ni la memoria ni los discos, pero cada nodo tiene inter¬ 
namente una arquitectura de memoria o de disco com¬ 
partido. 


20.2. PARALELISMO DE E/S 


En su forma más sencilla, el paralelismo de E/S se 
refiere a la reducción del tiempo necesario para recu¬ 
perar relaciones del disco dividiéndolas en varios 
discos. La forma más frecuente de división de datos 
en un entorno de bases de datos paralelas es la divi¬ 


sión horizontal. En la división horizontal, las tupias 
de las relaciones se dividen (o desagrupan) entre 
varios discos, de modo que cada tupia resida en un 
disco. Se han propuesto varias estrategias de divi¬ 
sión. 
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20.2.1. Técnicas de división 

Se presentan tres estrategias básicas para la división de 
datos. Se da por supuesto que hay n discos, D 0 , D¡,..., 
D nA , entre los cuales se van a dividir los datos. 

• Turno rotatorio. La relación se explora en cual¬ 
quier orden y la /-ésima tupia se envía al disco 
numerado D¡ mod n . El esquema de tumo rotatorio 
asegura una distribución homogénea de las tupias 
entre los discos; es decir, cada disco tiene aproxi¬ 
madamente el mismo número de tupias que los 
demás. 

• División por asociación. En esta estrategia de 
desagrupación uno o más atributos del esquema 
de la relación dada se designan como atributos de 
la división. Se escoge una función de asociación 
cuyo rango sea {0,1,..., n-l }. Cada tupia de la rela¬ 
ción original se asocia en términos de los atribu¬ 
tos de la división. Si la función de asociación 
devuelve i, la tupia se ubica en el disco D¡. 

• División por rangos. Esta estrategia distribuye 
rangos contiguos de valores de los atributos a cada 
disco. Se escoge un atributo de división, A , como 
vector de división. Sea [v 0 , v„..., v„. 2 ] el vector de 
división, tal que , si i<j, entonces v,< v ; . La rela¬ 
ción se divide como sigue. Considérese una tupia 
t tal que t\A\=x. Si x<v 0 entonces t se ubica en el 
disco Dq. Si x>v rh2 , entonces t se ubica en el disco 
D nA . Si v,< x < v ;+1 , entonces t se ubica en el dis¬ 
co D ¡+1 . 

Por ejemplo, la división por rangos con tres discos 
numerados del 0 al 2 puede asignar tupias con valores 
menores que 5 al disco 0, con valores entre 5 y 40 al 
disco 1, y con valores mayores que 40 al disco 2. 

20.2.2. Comparación de las técnicas de división 

Una vez se ha dividido una relación entre varios discos, 
se puede recuperar en paralelo utilizándolos todos. De 
modo parecido, cuando se está dividiendo una relación, 
se puede escribir en paralelo en varios discos. De esta 
manera las velocidades de transferencia para la lectura 
o escritura de una relación completa son mucho mayo¬ 
res con paralelismo de E/S que sin él. Sin embargo, la 
lectura de una relación completa, o exploración de la 
relación es sólo uno de los tipos de acceso a los datos. 
El acceso a los datos puede clasificarse de la manera 
siguiente: 

1. Explorar la relación completa. 

2. Localizar una tupia de manera asociativa (por 
ejemplo, nombre-empleado = «García»); estas 
consultas, denominadas consultas concretas, 
buscan tupias que tengan un valor concreto para 
un atributo concreto. 


3. Localizar todas las tupias cuyo valor de un atri¬ 
buto dado se halle en un rango especificado (por 
ejemplo, 10.000 <smé’Mo< 20.000); estas consul¬ 
tas se denominan consultas de rangos. 

Las diferentes técnicas de división permiten estos tipos 
de acceso a diferentes niveles de eficacia: 

• Turno rotatorio. El esquema se adapta perfecta¬ 
mente a las aplicaciones que desean leer secuen- 
cialmente la relación completa para cada consul¬ 
ta. Con este esquema tanto las consultas concretas 
como las de rangos son difíciles de procesar, dado 
que se debe emplear en la búsqueda cada uno de 
los n discos. 

• División por asociación. Este esquema se adapta 
mejor a las consultas concretas basadas en el atri¬ 
buto de división. Por ejemplo, si se divide una rela¬ 
ción en términos del atributo número-teléfono , se 
puede responder a la consulta «Buscar el registro 
del empleado con número-teléfono = 5553333» apli¬ 
cando la función de división por asociación a 
5553333 y buscando luego en ese disco. Dirigir la 
consulta a un solo disco ahorra el costo inicial de ini¬ 
ciar una consulta en varios discos y deja a los demás 
discos libres para procesar otras consultas. 

La división por asociación también es útil para 
las exploraciones secuenciales de la relación com¬ 
pleta. Si la función de asociación es una buena fun¬ 
ción aleatoria y los atributos de división forman 
una clave de la relación, el número de tupias en 
cada uno de los discos es aproximadamente el mis¬ 
mo, sin mucha varianza. Por tanto, el tiempo 
empleado para explorar la relación es aproxima¬ 
damente \/n del tiempo necesario para explorar la 
relación en un sistema de disco único. 

El esquema, sin embargo, no se adapta bien a 
las búsquedas concretas en términos de atributos 
que no sean de división. La división basada en aso¬ 
ciación tampoco se adapta bien a las respuestas a 
consultas de rangos, dado que, generalmente, las 
funciones de asociación no conservan la proximi¬ 
dad dentro de los rangos. Por tanto, hace falta 
explorar todos los discos para responder a las con¬ 
sultas de rangos. 

• División por rangos. Este esquema se adapta bien 
a las consultas concretas y de rangos basadas en 
el atributo de división. Para las consultas concre¬ 
tas se puede consultar el vector de división para 
encontrar el disco en el que reside la tupia. Para 
las consultas de rangos se consulta el vector de 
división para hallar el rango de discos en que pue¬ 
den residir las tupias. En ambos casos la búsque¬ 
da se limita exactamente a aquellos discos que 
pudieran tener tupias de interés. 

Una ventaja de esta característica es que, si sólo 
hay unas pocas tupias en el rango consultado, la 
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consulta se suele enviar a un disco, en vez de hacer¬ 
lo a todos. Dado que se pueden utilizar otros dis¬ 
cos para responder a otras consultas, la división 
por rangos da lugar a una mayor productividad de 
consultas al tiempo que se mantiene un buen tiem¬ 
po de respuesta. Por otro lado, si hay muchas tupias 
en el rango consultado (como ocurre cuando el ran¬ 
go consultado es una fracción mayor del dominio 
de la relación), hay que recuperar muchas tupias 
de pocos discos, lo que origina un cuello de bote¬ 
lla de E/S (punto caliente) en esos discos. En este 
ejemplo de sesgo de ejecución todo el procesa¬ 
miento tiene lugar en una partición (o en sólo unas 
pocas). Por el contrario, la división por asociación 
y de turno rotatorio usarían todos los discos para 
esas consultas, lo que daría un tiempo de respues¬ 
ta menor para aproximadamente la misma pro¬ 
ductividad. 

El tipo de división también afecta a otras operacio¬ 
nes relaciónales, como las reuniones, tal y como se verá 
en el Apartado 20.5. De este modo, la elección de la téc¬ 
nica de división también depende de las operaciones 
que haya que ejecutar. En general, las divisiones por 
asociación y en rangos se prefieren al turno rotatorio. 

En un sistema con muchos discos, el número de dis¬ 
cos en los que dividir una relación puede escogerse de 
la manera siguiente. Si una relación sólo contiene unas 
pocas tupias que caben en un solo bloque de disco, es 
mejor asignar la relación a uno solo. Las relaciones gran¬ 
des se dividen preferiblemente entre todos los discos 
disponibles. Si una relación consta de m bloques de dis¬ 
co y hay n discos disponibles en el sistema, se deberá 
ubicar la relación en min(/n,/?) discos. 

20.2.3. Tratamiento del sesgo 

La distribución de las tupias al dividir una relación 
(excepto para el turno rotatorio) puede estar sesgada, 
con un porcentaje alto de tupias ubicado en algunas divi¬ 
siones y menos en otros. La manera en que puede apa¬ 
recer el sesgo se clasifica de la manera siguiente: 

• Sesgo de los valores de los atributos. 

• Sesgo de la división. 

El sesgo de los valores de los atributos se refiere al 
hecho de que algunos valores pueden aparecer en los 
atributos de división de muchas tupias. Todas las tupias 
con el mismo valor del atributo de división terminan en 
la misma partición, lo que da lugar al sesgo. El sesgo 
de la división se refiere al hecho de que puede haber un 
desequilibrio en la carga de la división, aunque no haya 
sesgo en los atributos. 

El sesgo de los valores de los atributos puede dar 
lugar a una división sesgada independientemente de que 
se utilice división por rangos o por asociación. Si no se 
escoge cuidadosamente el vector de división, la divi¬ 


sión por rangos puede dar lugar a sesgo de división. El 
sesgo de división es menos probable con división por 
asociación si se ha escogido una buena función de aso¬ 
ciación. 

Como se indicó en el Apartado 18.3.1, incluso un 
sesgo pequeño puede dar lugar a una disminución sig¬ 
nificativa del rendimiento. El sesgo se transforma en un 
problema creciente al aumentar el grado de paralelis¬ 
mo. Por ejemplo, si una relación de 1.000 tupias se divi¬ 
de en 10 partes y la división está sesgada, puede haber 
algunas particiones de tamaño menor que 100 y otras 
de tamaño mayor que 100; si incluso da la casualidad 
de que una partición tiene tamaño 200, la aceleración 
que se obtendría al tener acceso en paralelo a las parti¬ 
ciones es sólo de cinco, en lugar del valor de diez que 
cabría esperar. Si la misma relación tiene que dividirse 
en 100 partes, las particiones tendrán de media diez 
tupias. Si una partición llega a tener hasta 40 tupias (lo 
que es posible dado el gran número de particiones) la 
aceleración que se obtendría al tener acceso a ellas en 
paralelo sería de 25, en vez de 100. Por tanto, se puede 
ver que la pérdida de aceleración debida al sesgo aumen¬ 
ta con el paralelismo. 

Se puede construir un vector de división por ran¬ 
gos equilibrado mediante ordenación. La relación pri¬ 
mero se ordena según los atributos de división. La rela¬ 
ción se explora a continuación de forma ordenada. 
Después de que cada l/n de la relación se haya leído, 
se añade el valor del atributo de división de la siguien¬ 
te tupia al vector de división. Aquí, n denota el núme¬ 
ro de particiones a construir. En el caso de que haya el 
mismo valor para el atributo de división, la técnica pue¬ 
de aún resultar en algo de sesgo. El inconveniente prin¬ 
cipal de este método es la sobrecarga de E/S debida a 
la ordenación inicial. 

La sobrecarga de E/S debida a la construcción de un 
vector de división por rangos equilibrado se puede redu¬ 
cir construyendo y almacenado una tabla de frecuencias, 
o histograma, de los valores de atributos para todo atri¬ 
buto de las relaciones. La Figura 20.1 muestra un ejem¬ 
plo de un histograma para un atributo de tipo entero que 



valor 

FIGURA 20.1. Ejemplo de histograma. 
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toma valores en el rango de 1 a 25. Los histogramas ocu¬ 
pan poco espacio, así que en el catálogo se pueden alma¬ 
cenar histogramas sobre diferentes atributos. Es senci¬ 
llo construir una función de división por rangos 
equilibrada dado un histograma sobre los atributos de 
división. Si no se almacena el histograma, se puede cal¬ 
cular de manera aproximada tomando muestras de la 
relación, usando sólo tupias de un subconjunto elegido 
aleatoriamente de los bloques de discos de la relación. 

Otro enfoque para minimizar el efecto del sesgo, par¬ 
ticularmente con una división por rangos, es usar pro¬ 
cesadores virtuales. En el enfoque de los procesado¬ 
res virtuales, se supone que hay varias veces 
procesadores virtuales como procesadores reales haya. 


Se puede usar cualquiera de las técnicas de división y 
de evaluación de consultas que se estudian más tarde 
en este capítulo, pero asignando las tupias a los proce¬ 
sadores virtuales en lugar de los reales. Los procesado¬ 
res virtuales, a su vez, se hacen corresponder con pro¬ 
cesadores reales, usualmente según una división por 
turno rotatorio. 

La idea es que incluso si un rango tiene muchas más 
tupias que los otros debido al sesgo, éstas se puedan 
repartir entre varios rangos de procesadores virtuales. 
La asignación por turno rotatorio de los procesadores 
virtuales a procesadores reales distribuiría el trabajo 
extra entre varios procesadores reales, de forma que nin¬ 
gún procesador tenga que asumir toda la carga. 


20.3. PARALELISMO ENTRE CONSULTAS 


En el paralelismo entre consultas se ejecutan en para¬ 
lelo entre sí diferentes consultas o transacciones. La pro¬ 
ductividad de transacciones puede aumentarse con esta 
forma de paralelismo. Sin embargo, el tiempo de res¬ 
puesta de cada transacción no es menor que si éstas se 
ejecutaran aisladamente. Por ello, el uso principal del 
paralelismo entre consultas es ampliar los sistemas de 
procesamiento de transacciones para permitir un núme¬ 
ro mayor de transacciones por segundo. 

El paralelismo entre consultas es la forma más sen¬ 
cilla de paralelismo que se permite en los sistemas de 
bases de datos, especialmente en sistemas paralelos de 
memoria compartida. Los sistemas de bases de datos 
diseñados para sistemas con un único procesador pue¬ 
den utilizarse en arquitecturas paralelas de memoria 
compartida con pocos cambios o con ninguno, dado que 
incluso los sistemas secuenciales de bases de datos per¬ 
miten el procesamiento concurrente. Las transacciones 
que se habrían realizado de manera concurrente en tiem¬ 
po compartido en una máquina secuencial se realizan 
en paralelo en la arquitectura paralela de memoria com¬ 
partida. 

Permitir el paralelismo entre consultas es más com¬ 
plicado en las arquitecturas de disco compartido y sin 
compartimiento. Los procesadores tienen que realizar 
algunas tareas, como los bloqueos y el registro históri¬ 
co, de forma coordinada, y eso exige que se intercam¬ 
bien mensajes. Los sistemas con arquitectura paralela 
también deben asegurar que dos procesadores no actua¬ 
licen simultáneamente los mismos datos de manera inde¬ 
pendiente. Además, cuando un procesador tiene acceso 
a los datos o los actualiza, el sistema de bases de datos 
debe asegurar que el procesador tenga la última versión 
de éstos en su memoria intermedia. Este último pro¬ 
blema se conoce como problema de coherencia caché. 

Se han desarrollado varios protocolos para garanti¬ 
zar la coherencia caché; a menudo los protocolos de 
coherencia caché se integran con los de control de la 


concurrencia de modo que se reduzca la sobrecarga. Un 
protocolo de este tipo para sistemas de disco comparti¬ 
do es de la manera siguiente: 

1. Antes de cualquier acceso de lectura o de escri¬ 
tura a una página, una transacción la bloquea en 
modo compartido o exclusivo, según correspon¬ 
da. Inmediatamente después de que la transacción 
obtenga un bloqueo compartido o exclusivo de la 
página, lee también la copia más reciente de la 
misma del disco compartido. 

2. Antes de que una transacción libere un bloqueo 
exclusivo de la página, traslada ésta al disco com¬ 
partido; luego, libera el bloqueo. 

El protocolo anterior asegura que, cuando una transac¬ 
ción establezca un bloqueo compartido o exclusivo sobre 
una página, obtenga la copia correcta de la página. 

Se han desarrollado protocolos más complejos para 
evitar la lectura y escritura reiteradas del disco exigidas 
por el protocolo anterior. Con estos protocolos las pági¬ 
nas no se escriben en el disco cuando se liberan los blo¬ 
queos exclusivos. Cuando se obtiene un bloqueo com¬ 
partido o exclusivo, si la versión más reciente de la 
página está en la memoria intermedia de algún proce¬ 
sador, se obtiene de allí. Los protocolos tienen que dise¬ 
ñarse para tratar peticiones concurrentes. Los protoco¬ 
los de disco compartido pueden extenderse a las 
arquitecturas sin compartimiento de la manera siguien¬ 
te. Cada página tiene un procesador local P¡ y se guar¬ 
da en el disco D¡. Cuando otros procesadores quieran 
leer la página o escribir en ella, enviarán peticiones a 
su procesador local P¡, dado que no pueden comunicarse 
directamente con el disco. Las otras acciones son igua¬ 
les que en los protocolos de disco compartido. 

Los sistemas Oracle 8 y Oracle Rdb son ejemplos de 
sistemas paralelos de bases de datos de disco compar¬ 
tido que permiten paralelismo entre consultas. 
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20.4. PARALELISMO EN CONSULTAS 


El paralelismo en consultas se refiere a la ejecución 
en paralelo de una única consulta en varios procesado¬ 
res y discos. El uso del paralelismo en consultas es 
importante para acelerar las consultas de ejecución lar¬ 
ga. El paralelismo entre consultas no ayuda en esta labor, 
dado que cada consulta se ejecuta de manera secuen- 
cial. 

Para ilustrar la evaluación en paralelo de una con¬ 
sulta considérese una que exija que se ordene una rela¬ 
ción. Supóngase que la relación se ha dividido en varios 
discos mediante la división por rangos basada en algún 
atributo y que se solicita la ordenación basada en el atri¬ 
buto de división. La operación de ordenación se puede 
realizar de la manera siguiente: cada partición se orde¬ 
na en paralelo y las particiones ordenadas se concate¬ 
nan para obtener la relación ordenada final. 

Por tanto, se puede hacer paralela una consulta 
haciendo paralelas las operaciones que la forman. Hay 
otra fuente de paralelismo para la evaluación de las con¬ 
sultas: el árbol de operadores de una consulta puede 
contener varias operaciones. Se puede hacer paralela la 
evaluación del árbol de operadores evaluando en para¬ 
lelo algunas de las operaciones que no tengan ninguna 
dependencia entre sí. Además, como se mencionó en el 
Capítulo 13, puede que se logre encauzar el resultado 
de una operación hacia otra. Las dos operaciones pue¬ 
den ejecutarse en paralelo en procesadores separados, 
uno que genere el resultado que consuma el otro, inclu¬ 
so simultáneamente con su generación. 

En resumen, la ejecución de una sola consulta pue¬ 
de hacerse en paralelo de dos maneras: 

• Paralelismo en operaciones. Se puede acelerar el 
procesamiento de consultas haciendo paralela la 
ejecución de cada una de las operaciones, como 
puede ser la ordenación, la selección, la proyec¬ 
ción y la reunión. El paralelismo en operaciones 
se considera en el Apartado 20.5. 

• Paralelismo entre operaciones. Se puede acele¬ 
rar el procesamiento de consultas ejecutando en 
paralelo las diferentes operaciones de las expre¬ 


siones de las consultas. Esta forma de paralelismo 
se considera en el Apartado 20.6. 

Las dos formas de paralelismo son complementarias 
y pueden utilizarse simultáneamente en una misma con¬ 
sulta. Dado que el número de operaciones de una con¬ 
sulta típica es pequeño comparado con el número de 
tupias procesado por cada operación, la primera forma 
de paralelismo puede adaptarse mejor a su aumento. Sin 
embargo, con el número relativamente pequeño de pro¬ 
cesadores de los sistemas paralelos típicos de hoy en 
día, ambas formas de paralelismo son importantes. 

En la discusión siguiente sobre la paralelización en 
las consultas se da por supuesto que éstas son sólo de 
lectura. La elección de algoritmos para evaluar en para¬ 
lelo las consultas depende de la arquitectura de la máqui¬ 
na. En lugar de presentar por separado los algoritmos 
para cada arquitectura se utilizará en la descripción un 
modelo de arquitectura sin compartimiento. Así, se des¬ 
cribirá explícitamente el momento en que los datos 
deben transferirse de un procesador a otro. Este mode¬ 
lo se puede simular con facilidad utilizando las otras 
arquitecturas, dado que la transferencia de los datos pue¬ 
de realizarse mediante la memoria compartida en las 
arquitecturas de memoria compartida y mediante los 
discos compartidos en las arquitecturas de discos com¬ 
partidos. Por tanto, los algoritmos para las arquitectu¬ 
ras sin compartimiento también pueden utilizarse en las 
demás arquitecturas. Ocasionalmente se menciona la 
manera en que se pueden optimizar aún más los algo¬ 
ritmos para los sistemas de memoria o de discos com¬ 
partidos. 

Para simplificar la exposición de los algoritmos se 
da por supuesto que hay n procesadores, P 0 ,..., P nA y n 
discos, D 0 , ..., D iiA , donde el disco D¡ está asociado con 
el procesador/ 5 ,. Un sistema real puede tener varios dis¬ 
cos por cada procesador. No es difícil extender los algo¬ 
ritmos para permitir varios discos por procesador: bas¬ 
ta con suponer que D¡ sea un conjunto de discos. Sin 
embargo, en aras de la sencillez de la exposición, aquí 
se supondrá que D¡ es un solo disco. 


20.5. PARALELISMO EN OPERACIONES 


Dado que las operaciones relaciónales trabajan con rela¬ 
ciones que contienen grandes conjuntos de tupias, se 
pueden paralelizar las operaciones ejecutándolas en para¬ 
lelo en subconjuntos diferentes de las relaciones. Dado 
que el número de tupias de una relación puede ser gran¬ 
de, el grado de paralelismo es potencialmente enorme. 
Por tanto, el paralelismo en operaciones es natural en 
los sistemas de bases de datos. Las versiones paralelas 


de algunas operaciones relaciónales frecuentes se estu¬ 
diarán en los apartados 20.5.1 a 20.5.3. 

20.5.1. Ordenación en paralelo 

Supóngase que se desea ordenar una relación que resi¬ 
de en n discos, D 0 ,..., D nA . Si la relación se ha dividido 
por rangos basándose en los atributos por los que se va 
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a ordenar, entonces, como se indicó en el Apartado 

20.2.2, se puede ordenar por separado cada partición y 
concatenar los resultados para obtener la relación com¬ 
pleta ordenada. Dado que las tupias se hallan divididas 
en n discos, el tiempo necesario para leer la relación 
completa se reduce gracias al acceso en paralelo. 

Si la relación se ha dividido siguiendo algún otro 
método se puede ordenar de una de estas dos mane¬ 
ras: 

1. Se puede dividir en rangos de acuerdo con los 
atributos de ordenación y luego ordenar cada par¬ 
tición por separado. 

2. Se puede utilizar una versión paralela del algo¬ 
ritmo extemo de ordenación-mezcla. 

20.5.1.1. Ordenación con división por rangos 

La ordenación con división por rangos funciona en dos 
pasos: primero se divide por rangos la relación y des¬ 
pués se ordena cada partición. Cuando se ordena la rela¬ 
ción con división por rangos no hace falta dividir en 
rangos la relación en los mismos procesadores o discos 
en los que se guarda la relación. Supóngase que se esco¬ 
gen los procesadores P 0 , P l ,...,Pm, donde m<n para 
ordenar la relación. Hay dos pasos involucrados en esta 
operación: 

1. Hay que redistribuir la relación utilizando una 
estrategia de división por rangos, de manera que 
todas las tupias que se hallen dentro del rango i- 
ésimo se envíen al procesador P¡, que guarda tem¬ 
poralmente la relación en el disco D¡. 

Para implementar la división por rangos cada 
procesador lee en paralelo las tupias de su disco 
y envía las tupias al procesador destino. Cada pro¬ 
cesador P 0 , P ]t ...,Pm también recibe las tupias de 
su partición y las almacena localmente. Este paso 
exige una sobrecarga en la E/S de disco y de 
comunicaciones. 

2. Cada uno de los procesadores ordena localmen¬ 
te su partición de la relación sin interacción con 
los demás procesadores. Cada procesador ejecu¬ 
ta la misma operación —por ejemplo, ordenar— 
en un conjunto de datos diferente (la ejecución de 
la misma acción en paralelo en conjuntos dife¬ 
rentes de datos se denomina paralelismo de 
datos). 

La operación final de mezcla es trivial, ya que 
la división por rangos de la primera etapa asegu¬ 
ra que, para 1 <;</<m, los valores de la clave del 
procesador P¡ son todos menores que los de P r 

Hay que dividir por rangos utilizando un buen vec¬ 
tor de división por rangos, de manera que cada parti¬ 
ción tenga aproximadamente el mismo número de 
tupias. Los procesadores virtuales también se pueden 
utilizar para reducir el sesgo. 


20.5.1.2. Ordenación y mezcla externas 
paralelas 

Utilizar la ordenación y mezcla externas paralelas es 
una alternativa a la división por rangos. Supóngase que 
la relación ya se ha dividido entre los discos D Q , D x ,..., 
D n ] (no importa la manera en que se haya dividido la 
relación). La ordenación y la reunión extemas parale¬ 
las funcionan entonces de la siguiente manera: 

1. Cada procesador P¡ ordena localmente los datos 
en el disco D¡. 

2. Las partes ordenadas por cada procesador se mez¬ 
clan luego para obtener el resultado ordenado final. 

La mezcla de las partes ordenadas del paso 2 puede 
hacerse en paralelo de la manera siguiente: 

1. Las particiones ordenadas en cada procesador P¡ 
se dividen en rangos (utilizando el mismo vector 
de división) en los procesadores P 0 , P lr ..P mA . 
Las tupias se envían de acuerdo con el orden de 
ordenación, por lo que cada procesador recibe las 
tupias en corrientes ordenadas. 

2. Cada procesador P¡ realiza una mezcla de las 
corrientes según las recibe para obtener una sola 
parte ordenada. 

3. Las partes ordenadas de los procesadores 
P 0 , P t .., P mA se concatenan para obtener el resul¬ 
tado final. 

Como se ha descrito, esta secuencia de acciones resul¬ 
ta en una forma interesante del sesgo de ejecución, ya 
que al principio cada procesador envía todos los blo¬ 
ques de la división 0 a P 0 , después cada procesador envía 
todos los bloques de la partición 1 a P l7 y así sucesiva¬ 
mente. Así, mientras que el envío sucede en paralelo, la 
recepción es secuencial: primero sólo P {] recibe tupias, 
luego sólo P x recibe tupias, y así sucesivamente. Para 
evitar este problema, cada procesador envía repetida¬ 
mente un bloque de datos a cada partición. En otras pala¬ 
bras, cada procesador envía el primer bloque de cada 
partición, después envía el segundo bloque de cada par¬ 
tición, y así sucesivamente. Como resultado, todos los 
procesadores reciben datos en paralelo. 

Algunas máquinas, como las de la serie DBC de Tera- 
data, utilizan hardware especializado para realizar la 
mezcla. La red de interconexión Y-net de las máquinas 
DBC de Teradata puede mezclar los resultados de varios 
procesadores para ofrecer un único resultado ordenado. 

20.5.2. Reunión paralela 

La operación reunión exige que se comparen pares de 
tupias para ver si satisfacen la condición de reunión: si 
lo hacen, el par se añade al resultado reunido. Los algo¬ 
ritmos de reunión paralela intentan repartir entre varios 
procesadores los pares que hay que comparar. Cada pro- 
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cesador procesa luego localmente parte de la reunión. 
Luego hay que reunir los resultados de cada procesador 
para producir el resultado final. 

20.5.2.1. Reunión por división 

Para ciertos tipos de reuniones, como las equirreunio- 
nes y las naturales, es posible dividir las dos relaciones 
de entrada entre los procesadores y procesar localmen¬ 
te la reunión en cada uno de ellos. Supóngase que se 
utilizan n procesadores y que las relaciones que hay que 
reunir son r y 5. Luego, cada una de las relaciones se 
divide en n particiones, denominadas r 0 , r¡,..r n] y s 0 , 
s j,..., s„_¡. Las particiones r¡ y s¡ se envían al procesa¬ 
dor P¡, donde la reunión se procesa localmente. 

La técnica anterior sólo funciona correctamente si la 
reunión es una equirreunión (por ejemplo, rtx rA=s B s) 
y, si se dividen ry s utilizando la misma función de divi¬ 
sión para sus atributos de reunión. La idea de la di¬ 
visión es exactamente la misma que la que subyace al 
paso de división de la reunión por asociación. Sin em¬ 
bargo, hay dos maneras diferentes de dividir r y s: 

• División por rangos de los atributos de reunión 

• División por asociación de los atributos de reu¬ 
nión. 

En cualquier caso se debe utilizar la misma función de 
división para las dos relaciones. Para la división por ran¬ 
gos se debe utilizar el mismo vector de división para las 
dos relaciones. Para la división por asociación esto sig¬ 
nifica que se debe utilizar la misma función de asocia¬ 
ción en las dos relaciones. La Figura 20.2 muestra la 
división utilizada en una reunión por división paralela. 

Una vez divididas las relaciones se puede utilizar 
localmente cualquier técnica de reunión en cada proce¬ 
sador P¡ para calcular la reunión de r¡ y s¡. Por ejemplo, 
se puede utilizar la reunión por asociación, la reunión 
por mezcla o la reunión con bucles anidados. Por tan- 



r 


to, se puede utilizar la división para paralelizar cual¬ 
quier técnica de reunión. 

Si alguna de las relaciones ryso ambas ya están 
divididas basándose en los atributos de reunión (median¬ 
te división por asociación o por rangos) el trabajo nece¬ 
sario para la división se reduce mucho. Si las relacio¬ 
nes no están divididas, o lo están basándose en atributos 
distintos de los de reunión, hay que volver a dividir las 
tupias. Cada procesador P¡ lee las tupias del disco D¡, 
procesa para cada tupia t la partición j a la que perte¬ 
nece y la envía al procesador P¡. El procesador P • guar¬ 
da las tupias en el disco D¡. 

Se puede optimizar el algoritmo de reunión utiliza¬ 
do localmente en cada procesador para reducir E/S no 
escribiendo en el disco algunas de las tupias sino guar¬ 
dándolas temporalmente en una memoria intermedia. 
Estas optimizaciones se describen en el Apartado 
20.5.2.3. 

El sesgo representa un problema especial cuando se 
utiliza división por rangos, dado que un vector de divi¬ 
sión que divida una relación de la reunión en particio¬ 
nes de igual tamaño puede dividir las demás relaciones 
en particiones de tamaño muy variable. El vector de 
división debe ser tal que lr,-l + I .v, I (es decir, la suma de 
los tamaños de r¡ y s¡) sea aproximadamente igual para 
todo i = 0, 1,_, n— 1. Con una buena función de aso¬ 

ciación, la división por asociación probablemente ten¬ 
ga menos sesgo, excepto cuando haya muchas tupias 
con los mismos valores de los atributos de reunión. 

20.5.2.2. Reunión con fragmentos y réplicas 

La división no es aplicable a todos los tipos de reunio¬ 
nes. Por ejemplo, si la condición de reunión es una desi¬ 
gualdad, como / XI ra<s b s, es posible que todas las tupias 
de r se reúnan con alguna tupia de s (y viceversa). Por 
tanto, puede que no baya medios no triviales de dividir 
rysde modo que las tupias de la partición r¡ se reúnan 
exclusivamente con tupias de la partición s¡. 

Esas reuniones pueden paralelizarse utilizando una 
técnica denominada fragmentos y réplicas. Primero se 
considerará un caso especial de fragmentos y réplicas 
—reunión con fragmentos y réplicas asimétricos— 
que funciona de la manera siguiente. 

1. Se divide una de las relaciones (digamos r). Se 
puede utilizar en r cualquier técnica de división, 
incluyendo la división por turno rotatorio. 

2. La otra relación, s, se replica entonces en todos 
los procesadores. 

3. El procesador P¡ procesa entonces localmente la 
reunión de r¡ con toda s, utilizando cualquier téc¬ 
nica de reunión. 

El esquema de fragmentos y réplicas asimétricos se 
muestra en la Figura 20.3a. Si r ya está guardada por 
particiones no hace falta dividirla más en el paso 1. Todo 
lo que hace falta es replicar s en todos los procesadores. 


FIGURA 20.2. Reunión por división en paralelo. 
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FIGURA 20.3. Esquemas de fragmentos y réplicas. 


El caso general de reunión con fragmentos y répli¬ 
cas se muestra en la Figura 20.3b; funciona de la mane¬ 
ra siguiente. La relación r se divide en n particiones, r 0 , 

r ..r n _! y 5 se divide en m particiones, % s mA . 

Igual que antes se puede utilizar cualquier técnica de 
división para r y para 5. Los valores de m y de n no tie¬ 
nen por qué ser iguales, pero deben escogerse de modo 
que haya al menos m * n procesadores. Los fragmentos 
y réplicas asimétricos sólo son un caso especial de los 
fragmentos y réplicas generales, donde m = 1. Los frag¬ 
mentos y réplicas reducen el tamaño de las relaciones 
en cada procesador en comparación con los fragmentos 
y réplicas asimétricos. 

Sean los procesadores P 00 , P 0 l ,..., P 0m _ ly P l 0 ,..., 
P n -i, m - 1 - El procesador P L/ procesa la reunión de r¡ con 
Sj. Para ello se replica r¡ en los procesadores P i0 , P lh .. 
P im _i (que forman una fila en la Figura 20.3b) y s¡ en 
los procesadores P 0¡ , P u ,..., P„_i ti (que forman una 
columna en la Figura 20.3b). Se puede utilizar cualquier 
técnica de reunión en cada procesador P tj . 

Los fragmentos y réplicas funcionan con cualquier 
condición de reunión, dado que todas las tupias de r 
pueden compararse con todas las tupias de s. Por tan¬ 
to, puede utilizarse cuando no pueda emplearse la divi¬ 
sión. 

Los fragmentos y réplicas suelen tener un mayor cos¬ 
te que la división cuando ambas relaciones son aproxi¬ 
madamente del mismo tamaño, dado que hay que repli¬ 
car al menos una de las relaciones. Sin embargo, si una 
de las relaciones (digamos s) es pequeña, puede resul¬ 
tar más barato replicar s en todos los procesadores que 
volver a dividir r y ,v basándose en los atributos de reu¬ 


nión. En tal caso, los fragmentos y réplicas asimétricos 
son preferibles, aunque pueda utilizarse la división. 

20.5.2.3. Reunión por asociación dividida 
en paralelo 

En este apartado se muestra la manera en que la reunión 
por asociación dividida del Apartado 13.5.5 puede hacer¬ 
se en paralelo. Supóngase que se tienen n procesado¬ 
res, P 0 , P { P n _ j y dos relaciones, ry s que se encuen¬ 
tran divididas en varios discos. Hay que recordar del 
Apartado 12.6 que se debe escoger la relación menor 
como relación de construcción. Si el tamaño de 5 es 
menor que el de r, el algoritmo de reunión por asocia¬ 
ción procede de la manera siguiente: 

1. Se escoge una función de asociación (digamos 
h x ) que tome el valor del atributo de reunión de 
cada tupia y asigne esta tupia a uno de los n pro¬ 
cesadores. Sean las tupias de la relación r que 
se envían al procesador/ 5 ,; de manera similar, sean 
s¡ las tupias de la relación s que se envían al pro¬ 
cesador P¡. Cada procesador P lee las tupias de 5 
que están en el disco D¡y envía cada tupia al pro¬ 
cesador apropiado basándose en la función de aso¬ 
ciación /Zj. 

2. Según se reciben en el procesador de destino P¡ 
las tupias de s¡, se vuelven a dividir utilizando otra 
función de asociación, h 2 , que el procesador uti¬ 
liza para procesar localmente la reunión por aso¬ 
ciación. La división en esta etapa es exactamen¬ 
te la misma que en la fase de división del 
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algoritmo secuencial de reunión por asociación. 
Cada procesador P¡ ejecuta este paso indepen¬ 
dientemente de los demás procesadores. 

3. Una vez que se han distribuido las tupias de s, el 
sistema redistribuye la relación mayor, r, entre 
los n procesadores utilizando la función de aso¬ 
ciación /;j del mismo modo que anteriormente. 
Según se recibe cada tupia, el procesador de des¬ 
tino la divide utilizando la función h 2 , igual que 
la relación de prueba se divide en el algoritmo 
secuencial de reunión por asociación. 

4. Cada procesador P¡ ejecuta las fases de construc¬ 
ción y prueba del algoritmo de reunión por aso¬ 
ciación en las particiones locales r¡ y s¡ para pro¬ 
ducir una división del resultado final de la reunión 
por asociación. 

La reunión por asociación realizada en cada proce¬ 
sador es independiente de las realizadas en otros pro¬ 
cesadores, y recibir las tupias de r¡ y de s¡ es parecido a 
leerlas del disco. Por tanto, cualquiera de las optimiza¬ 
ciones de la reunión por asociación descritas en el Capí¬ 
tulo 13 pueden aplicarse también al caso paralelo. En 
concreto, se puede utilizar el algoritmo híbrido de reu¬ 
nión por asociación para guardar en caché algunas de 
las tupias de entrada, y evitar así los costes de escribir¬ 
las y volver a leerlas. 

20.5.2.4. Reuniones con bucles anidados 
en paralelo 

Para ilustrar el uso de la paralelización basada en frag¬ 
mentos y réplicas se considera el caso en que la relación 
5 sea mucho menor que la relación r. Supóngase también 
que la relación r se guarda dividiéndola; el atributo según 
el que se divide es irrelevante. Finalmente, supóngase 
que hay un índice basado en un atributo de reunión de la 
relación r en cada uno de las particiones de la relación r. 

Se utilizan los fragmentos y réplicas asimétricos, 
mientras se replica la relación 5 y se utiliza la división 
existente de la relación r. Cada procesador P • en que se 
guarda una partición de la relación 5 lee las tupias de la 
relación s guardadas en D ; y replica las tupias en el res¬ 
to de procesadores P¡. Al final de esta fase la relación s 
está replicada en todos los puntos que guardan tupias 
de la relación r. 

Ahora, cada procesador P¡ realiza una reunión con 
bucles anidados indexada de la relación s con la parti¬ 
ción í-ésima de la relación r. Se puede solapar la reu¬ 
nión con bucles anidados indexada con la distribución 
de las tupias de la relación s para reducir los costes de 
escribir en el disco las tupias de la relación s y de vol¬ 
ver a leerlas. Sin embargo, la réplica de la relación 5 
debe sincronizarse con la reunión para que haya espa¬ 
cio suficiente en las memorias intermedias de la memo¬ 
ria principal de cada procesador P¡ para guardar las 
tupias de la relación s que se hayan recibido pero que 
todavía no se han utilizado en la reunión. 


20.5.3. Otras operaciones relaciónales 

También se puede realizar en paralelo la evaluación de 
otras operaciones relaciónales: 

• Selección. Sea la selección o g (r). Considérese pri¬ 
mero el caso en el que 0 es de la forma a¡ = v, don¬ 
de a¡ es un atributo y v es un valor. Si la relación 
;• se divide basándose en a¡ la selección se lleva 
a cabo en un solo procesador. Si 9 es de la forma 
1 <a¡< u (es decir, que 6 es una selección de ran¬ 
go) y la relación se ha dividido por rangos basán¬ 
dose en a¡, entonces la selección se lleva a cabo en 
cada procesador cuya partición se solape con el 
rango de valores especificado. En el resto de los 
casos la selección se lleva a cabo en todos los pro¬ 
cesadores en paralelo. 

• Eliminación de duplicados. La eliminación de 
duplicados puede llevarse a cabo por ordenación; 
puede utilizarse cualquiera de las técnicas de orde¬ 
nación en paralelo, con la optimización de elimi¬ 
nar los duplicados durante la ordenación tan pron¬ 
to como se encuentren. También se puede realizar 
la eliminación de duplicados en paralelo dividien¬ 
do las tupias (mediante división por rangos o por 
asociación) y llevando a cabo localmente en cada 
procesador la eliminación de duplicados. 

• Proyección. Se puede llevar a cabo la proyección 
sin eliminación de duplicados según se leen en 
paralelo las tupias del disco. Si se va a llevar a cabo 
la eliminación de duplicados se pueden utilizar las 
técnicas que se acaban de describir. 

• Agregación. La agregación puede considerarse 
una operación. Se puede paralelizar la operación 
dividiendo la relación basándose en los atributos 
de agrupación y procesando luego localmente los 
valores de agregación en cada procesador. Se pue¬ 
de utilizar división por rangos o por asociación. Si 
la relación ya está dividida basándose en los atri¬ 
butos de agrupación se puede omitir el primer paso. 

Se puede reducir el coste de transferir las tupias 
durante la división procesando parcialmente los 
valores de agregación antes de la división, al menos 
con las funciones de agregación utilizadas fre¬ 
cuentemente. Considérese una operación de agre¬ 
gación basada en una relación r, utilizando la fun¬ 
ción de agregación sum con el atributo B y la 
agrupación basada en el atributo A. La operación 
puede llevarse a cabo en cada procesador P¡ sobre 
las r tupias guardadas en el disco D¡. Este proce¬ 
so da lugar a tupias con sumas parciales en cada 
procesador; hay una tupia en P¡ para cada valor del 
atributo A presente en r tupias guardadas en D¡. El 
resultado de la agregación local se divide basán¬ 
dose en el atributo de agrupación A y la agrega¬ 
ción se vuelve a llevar a cabo (sobre las tupias con 
sumas parciales) en cada procesador P¡ para obte¬ 
ner el resultado final. 
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Como resultado de esta optimización no es 
necesario enviar tantas tupias a los demás proce¬ 
sadores durante la división. Esta idea puede exten¬ 
derse fácilmente a las funciones de agregación min 
y max. Las extensiones para las funciones de agre¬ 
gación count y avg se proponen al lector en el Ejer¬ 
cicio 20.8. 

La paralelización de otras operaciones se trata en 
varios ejercicios. 

20.5.4. Coste de la evaluación en paralelo 
de las operaciones 

Se puede obtener el paralelismo dividiendo la E/S entre 
varios discos y el trabajo de la UCP entre varios proce¬ 
sadores. Si se logra un reparto así sin sobrecarga y no 
hay sesgo en el reparto del trabajo, las operaciones en 
paralelo que utilicen n procesadores tardarán Un lo que 
tardarían en un solo procesador. Ya se sabe cómo esti¬ 
mar el coste de operaciones como la reunión o la selec¬ 
ción. El coste en tiempo del procesamiento paralelo sería 
entonces Un el del procesamiento secuencial de la ope¬ 
ración. 

También hay que tener en cuenta los costes siguientes: 

• Los costes de iniciar la operación en varios pro¬ 
cesadores. 

• El sesgo en la distribución de trabajo entre los pro¬ 
cesadores, con algunos procesadores con mayor 
número de tupias que otros. 

• La contención de recursos —como la memoria, 
los discos y la red de comunicaciones— que dan 
lugar a retrasos. 


• El coste de construir el resultado final transmitien¬ 
do los resultados parciales desde cada procesador. 

El tiempo empleado por una operación en paralelo 
puede estimarse como 

2"div + T’con + max(7 0 , 7j„. .,T n _ { ) 

Donde 7 dlv es el tiempo necesario para dividir las rela¬ 
ciones, T con es el tiempo empleado en construir los resul¬ 
tados y T¡ el tiempo utilizado por la operación en el pro¬ 
cesador P¡. Suponiendo que las tupias se distribuyen sin 
sesgo, el número de tupias enviadas a cada procesador 
puede estimarse como l/n del número total de tupias. 
Ignorando la contención, el coste T¡ de las operaciones 
en cada procesador P¡ puede estimarse entonces median¬ 
te las técnicas descritas en el Capítulo 13. 

La estimación precedente será una estimación opti¬ 
mista, dado que el sesgo es frecuente. Aunque dividir 
una sola consulta en varios pasos en paralelo reduce el 
tamaño del paso medio, es el tiempo de procesamiento 
del paso más lento el que determina el tiempo emplea¬ 
do en procesar la consulta en su conjunto. Una evalua¬ 
ción en paralelo de las particiones, por ejemplo, sólo es 
tan rápida como la más lenta de sus ejecuciones en para¬ 
lelo. Por tanto, el rendimiento se ve muy afectado por 
cualquier sesgo en la distribución del trabajo entre los 
procesadores. 

El problema del sesgo de la división está íntimamente 
relacionado con el del desbordamiento de particiones 
en las reuniones por asociación secuenciales (Capítulo 
13). Se puede utilizar la resolución del desbordamien¬ 
to y las técnicas de evitación desarrolladas para las reu¬ 
niones por asociación para tratar el sesgo cuando se uti¬ 
lice la división por asociación. 


20.6. PARALELISMO ENTRE OPERACIONES 


Hay dos formas de paralelismo entre operaciones: el 
paralelismo de encauzamiento y el paralelismo inde¬ 
pendiente. 

20.6.1. Paralelismo de encauzamiento 

Como se discutió en el Capítulo 13, el encauzamiento 
supone una importante fuente de economía de procesa¬ 
miento para el procesamiento de consultas de bases de 
datos. Hay que recordar que, en el encauzamiento, las 
tupias resultado de una operación, A , las consume una 
segunda operación, B, incluso antes de que la primera 
operación haya producido el conjunto completo de tupias 
de su resultado. La ventaja principal de la ejecución 
encauzada de las evaluaciones secuenciales es que se 
puede ejecutar una secuencia de operaciones de ese tipo 
sin escribir en el disco ninguno de los resultados inter¬ 
medios. 


En los sistemas paralelos el encauzamiento se utili¬ 
za principalmente por la misma razón que en los siste¬ 
mas secuenciales. Sin embargo, el encauzamiento pue¬ 
de utilizarse también como fuente de paralelismo, del 
mismo modo que el encauzamiento de instrucciones se 
utiliza como fuente de paralelismo en el diseño de hard¬ 
ware. En el ejemplo anterior es posible ejecutar simul¬ 
táneamente Ay B en procesadores diferentes de modo 
que B consuma las tupias en paralelo con su producción 
por A. Esta forma de paralelismo se denomina parale¬ 
lismo de encauzamiento. 

Consideremos una reunión de cuatro relaciones: 

r, XI r 2 X r 3 X r 4 

Se puede configurar un cauce que permita que las 
tres reuniones se procesen en paralelo. Supóngase que 
se asigna al procesador P x el cálculo de temp l r w X 
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r 2 y al procesador P 2 el cálculo de r 3 IX temp { . Mientras 
P l procesa las tupias de r ] tx r 2 las pone a disposición 
del procesador P 2 . Por tanto, P 2 tiene a su disposición 
algunas de las tupias de /', x¡ r 2 antes de que P l haya 
finalizado su cálculo. P 2 puede utilizar esas tupias que 
están disponibles para comenzar el cálculo de temp l XI 
r 3 , incluso antes de que P¡ haya procesado completa¬ 
mente r, tx r 2 . De manera parecida, mientras P 2 proce¬ 
sa las tupias de (r, XI r 2 ) tx r 3 , pone estas tupias a dis¬ 
posición de P 3 , que procesa la reunión de estas tupias 
con r 4 . 

El paralelismo encauzado resulta útil con un núme¬ 
ro pequeño de procesadores, pero no puede extenderse 
bien. En primer lugar, las cadenas del cauce no suelen 
lograr la longitud suficiente para proporcionar un alto 
grado de paralelismo. En segundo lugar, no es posible 
encauzar los operadores de relación que no producen 
resultados hasta que se ha tenido acceso a todas las entra¬ 
das, como la operación diferencia de conjuntos. En ter¬ 
cer lugar, sólo se obtiene una aceleración marginal en 
los casos frecuentes en que el coste de ejecución de un 
operador es mucho mayor que los de los demás opera¬ 
dores. 

Por consiguiente, cuando el grado de paralelismo es 
elevado, la importancia del encauzamiento como fuen¬ 
te de paralelismo es secundaria respecto de la del para¬ 
lelismo de particiones. La razón fundamental para uti¬ 
lizar el encauzamiento es que las ejecuciones encauzadas 
pueden evitar escribir en el disco los resultados inter¬ 
medios. 

20.6.2. Paralelismo independiente 

Las operaciones en las expresiones de las consultas que 
son independientes entre sí pueden ejecutarse en para¬ 
lelo. Esta forma de paralelismo se denomina paralelis¬ 
mo independiente. 

Considérese nuevamente la reunión r x M r 2 M r 3 Xl 
r 4 . Claramente, se puede procesar temp ] r, ix r 2 en 
paralelo con temp 2 <— r 3 xi r 4 . Cuando se completen 
estos dos cálculos se calculará 

temp 3 \A temp 2 

Para obtener más paralelismo se pueden encauzar las 
tupias de tenip l y de temp 2 al cálculo de lemp , txi temp 2 , 
que se ejecuta mediante una reunión encauzada (Apar¬ 
tado 13.7.2.2). 

Al igual que el paralelismo encauzado, el parale¬ 
lismo independiente no proporciona un alto grado de 
paralelismo y es menos útil en sistemas con un ele¬ 
vado nivel de paralelismo, aunque resulta útil con un 
grado menor de paralelismo. 

20.6.3. Optimización de consultas 

Un factor importante en el éxito de la tecnología rela- 
cional ha sido el diseño con éxito de optimizadores de 


consultas. Recuérdese que un optimizador de consultas 
toma una consulta y encuentra el plan de ejecución más 
económico de entre los muchos planes de ejecución 
posibles que proporcionan la misma respuesta. 

Los optimizadores de consultas para la evaluación 
de consultas en paralelo son más complicados que los 
optimizadores de consultas para la evaluación secuen- 
cial de consultas. En primer lugar, los modelos de cos¬ 
tes son más complicados dado que hay que tener en 
cuenta los costes de división, y deben tenerse en consi¬ 
deración aspectos como el sesgo y la contención de 
recursos. Resulta de mayor importancia el asunto de la 
paralelización de las consultas. Supóngase que de algún 
modo se ha escogido una expresión (de entre las equi¬ 
valentes a la consulta) para utilizarla para evaluar la 
consulta. La expresión puede representarse por un árbol 
de operadores, tal y como se discute en el Apartado 13.1. 

Para evaluar un árbol de operadores en un sistema 
paralelo hay que tomar las decisiones siguientes: 

• El modo en que se paralelice cada operación y el 
número de procesadores que se utilizará para ello. 

• Las operaciones que se encauzan entre los dife¬ 
rentes procesadores, las operaciones que se ejecu¬ 
ten independientemente en paralelo y las que se 
ejecuten secuencialmente, una tras otra. 

Estas decisiones constituyen la tarea de planificar el 
árbol de ejecución. 

Determinar los recursos de cada clase —como pro¬ 
cesadores, discos y memoria— que se deben asignar a 
cada operación del árbol es otro aspecto del problema 
de la optimización. Por ejemplo, puede que parezca con¬ 
veniente utilizar la máxima cantidad disponible de para¬ 
lelismo, pero es una buena idea no ejecutar en paralelo 
ciertas operaciones. Las operaciones cuyos requisitos 
operativos sean significativamente menores que la sobre¬ 
carga de comunicaciones deben agruparse con una de 
sus vecinas. En caso contrario, la ventaja del paralelis¬ 
mo se anula por sobrecarga en las comunicaciones. 

Una preocupación cuando se utiliza el encauzamiento 
es que los cauces largos no se presten a una buena uti¬ 
lización de los recursos. A menos que las operaciones 
tengan grano grueso, puede que la operación final del 
encauzamiento espere mucho tiempo para obtener sus 
entradas, mientras retiene recursos preciosos, como la 
memoria. Por tanto, deben evitarse los cauces largos. 

El número de planes de evaluación en paralelo de 
entre los que se puede escoger es mucho mayor que el 
de planes de evaluación secuenciales. Optimizar las con¬ 
sultas en paralelo considerando todas las alternativas es 
por tanto mucho más costoso que optimizar las consul¬ 
tas secuenciales. Por tanto, se suelen adoptar enfoques 
heurísticos para reducir el número de planes de ejecu¬ 
ción en paralelo que se considera. A continuación se 
describen dos heurísticas muy conocidas. 

La primera heurística es considerar únicamente los 
planes de evaluación que paralelizan todas las operacio- 
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nes de todos los procesadores y no utilizan encauza- 
miento. Este enfoque se utiliza en las máquinas de la serie 
DBC de Teradata. Buscar el mejor plan de ejecución de 
este tipo es parecido a realizar la optimización de con¬ 
sultas en sistemas secuenciales. Las principales diferen¬ 
cias radican en la manera de llevar a cabo la división y 
en las fórmulas de estimación de costes utilizadas. 

La segunda heurística es escoger el plan de evalua¬ 
ción secuencial más eficiente y luego paralelizar las ope¬ 
raciones de ese plan de evaluación. La base de datos para¬ 
lela Volcano ha popularizado el modelo de paralelización 
denominado intercambio de operadores. Este modelo 
usa implementaciones existentes de operaciones, actuan¬ 
do sobre copias locales de los datos, junto con una ope¬ 


ración de intercambio que traslada los datos entre dife¬ 
rentes procesadores. Los operadores de intercambio se 
pueden introducir en un plan de evaluación para trans¬ 
formarlo en un plan de evaluación en paralelo. 

Otra dimensión más de la optimización es el diseño 
de la organización del almacenamiento físico para ace¬ 
lerar las consultas. La organización física óptima es dife¬ 
rente para consultas diferentes. El administrador de la 
base de datos debe escoger una organización física que 
se considere adecuada para la combinación esperada de 
consultas a la base de datos. 

Por tanto, el área de la optimización de consultas en 
paralelo es compleja y sigue siendo un campo de inves¬ 
tigación activa. 


20.7. DISEÑO DE SISTEMAS PARALELOS 


Hasta ahora, en este capítulo hemos centrado la aten¬ 
ción en la paralelización del almacenamiento de los 
datos y en el procesamiento de consultas. Dado que los 
sistemas paralelos de bases de datos de gran escala se 
utilizan principalmente para almacenar grandes volú¬ 
menes de datos y para procesar consultas de ayuda a las 
decisiones basadas en dichos datos, estos temas son los 
más importantes en los sistemas paralelos de bases de 
datos. La carga de datos en paralelo desde fuentes exter¬ 
nas es un requisito importante si se van a tratar grandes 
volúmenes de datos entrantes. 

Un gran sistema paralelo de bases de datos debe abor¬ 
dar también los siguientes aspectos de disponibilidad: 

• El poder de recuperación frente al fallo de algu¬ 
nos procesadores o discos 

• La reorganización interactiva de los datos y los 
cambios de los esquemas. 

Estos temas se tratan a continuación. 

Con un gran número de procesadores y de discos la 
probabilidad de que al menos un procesador o un dis¬ 
co funcionen mal es significativamente mayor que en 
sistema con un único procesador y un solo disco. Un 
sistema paralelo mal diseñado dejará de funcionar si 
cualquier componente (procesador o disco) falla. Supo¬ 
niendo que la probabilidad de fallo de cada procesador 
o disco es pequeña, la probabilidad de fallo del sistema 
asciende linealmente con el número de procesadores y 
de discos. Si un solo procesador o disco falla una vez 
cada 5 años, un sistema con 100 procesadores tendrá un 
fallo cada 18 días. 

Por tanto, los sistemas paralelos de bases de datos 
de gran escala, como las máquinas Himalaya de Com¬ 
paq, Teradata y XPS de Informix (ahora una división 
de IBM), se diseñan para operar incluso si falla un pro¬ 


cesador o un disco. Los datos se replican en al menos 
dos procesadores. Si falla un procesador se puede seguir 
teniendo acceso desde los demás procesadores a los 
datos que guarda. El sistema hace un seguimiento de 
los procesadores con fallos y distribuye el trabajo entre 
los que funcionan. Las peticiones de los datos guarda¬ 
dos en el emplazamiento con fallo se desvían automá¬ 
ticamente a los emplazamientos de las copias de segu¬ 
ridad que guardan una réplica de los datos. Si todos los 
datos de un procesador A se replican en un solo proce¬ 
sador B, B tratará todas las peticiones hechas a A, así 
como las propias, y eso dará lugar a que B se transfor¬ 
me en un cuello de botella. Por tanto, las réplicas de los 
datos de un procesador se dividen entre varios proce¬ 
sadores. 

Cuando se manejan grandes volúmenes de datos (del 
orden de terabytes), las operaciones sencillas, como la 
creación de índices, y los cambios en los esquemas, 
como añadir una columna a una relación, pueden tardar 
mucho tiempo (quizás horas o incluso días). Por tanto, 
es inaceptable que los sistemas de bases de datos no 
estén disponibles mientras se llevan a cabo tales opera¬ 
ciones. Los sistemas paralelos de bases de datos, como 
los sistemas Himalaya de Compaq, permiten que tales 
operaciones se lleven a cabo interactivamente, es decir, 
mientras el sistema ejecuta otras transacciones. 

Considérese, por ejemplo, la construcción interac¬ 
tiva de índices. Un sistema que permita esta prestación 
permite que se realicen inserciones, borrados y actuali¬ 
zaciones en una relación aunque se esté generando un 
índice de la misma. La operación de generación de índi¬ 
ces, por tanto, no puede bloquear toda la relación en modo 
compartido, como habría hecho en caso contrario. En su 
lugar, el proceso hace un seguimiento de las actualiza¬ 
ciones que tienen lugar mientras está activo e incorpora 
los cambios en el índice que se está generando. 
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20.8. RESUMEN 


• Las bases de datos en paralelo han logrado una acep¬ 
tación comercial significativa en los últimos 15 años. 

• En el paralelismo de E/S las relaciones se dividen 
entre los discos disponibles para que se pueda reali¬ 
zar la recuperación de datos más rápidamente. Tres 
técnicas de división utilizadas frecuentemente son la 
división por turno rotatorio, la división por asocia¬ 
ción y la división por rangos. 

• El sesgo es un problema importante, especialmente 
con los grados crecientes de paralelismo. Los vecto¬ 
res de división equilibrados, usando histogramas, y 
la división con procesadores virtuales son algunas téc¬ 
nicas usadas para reducir el sesgo. 

• En el paralelismo entre consultas se ejecutan concu¬ 
rrentemente diferentes consultas para aumentar la pro¬ 
ductividad. 

• El paralelismo en las consultas intenta reducir el cos¬ 
te de ejecutar una consulta. Hay dos tipos de parale¬ 
lismo en las consultas: el paralelismo en operaciones 
y el paralelismo entre operaciones. 

• El paralelismo en operaciones se utiliza para ejecu¬ 
tar operaciones relaciónales, como las ordenaciones 
y las reuniones, en paralelo. El paralelismo en ope¬ 
raciones es natural en las operaciones relaciónales, 
dado que están orientadas a conjuntos. 


• Hay dos enfoques básicos en la paralelización de las 
operaciones binarias como las reuniones. 

— En el paralelismo de particiones las relaciones se 
dividen en varias partes y las tupias de r¡ sólo se 
reúnen con las tupias de s¡. El paralelismo de par¬ 
ticiones se puede usar sólo para las reuniones natu¬ 
rales y las equirreuniones. 

— En los fragmentos y réplicas asimétricos una de 
las relaciones se replica mientras la otra se divi¬ 
de. A diferencia del paralelismo de particiones, 
los fragmentos y réplicas pueden utilizarse con 
cualquier condición de reunión. Ambas técnicas 
de paralelismo pueden utilizarse en combinación 
con cualquier técnica de reunión. 

Ambas técnicas de paralelización pueden funcionar en 
conjunción con cualquier técnica de reunión. 

• En el paralelismo independiente las diferentes opera¬ 
ciones que no tienen dependencia entre sí se ejecutan 
en paralelo. 

• En el paralelismo encauzado los procesadores envían 
los resultados de una operación a otra según los van pro¬ 
cesando, sin esperar a que concluya toda la operación. 

• La optimización de consultas en bases de datos para¬ 
lelas es significativamente más compleja que la opti¬ 
mización de consultas en bases de datos secuenciales. 


TÉRMINOS DE REPASO 


• Atributo de división 

• Coherencia caché 

• Construcción interactiva de índices 

• Consulta concreta 

• Consulta de rangos 

• Consultas de ayuda a la toma de decisiones 

• Coste de la evaluación paralela 

• Diseño de sistemas paralelos 

• División horizontal 

• Eliminación de duplicados en paralelo 

• Manejo del sesgo 

- Histograma 

- Procesadores virtuales 

- Vector de división por rangos equilibrado 

• Modelo del operador de intercambio 

• Optimización de consultas 

• Ordenación paralela 

- Ordenación con división por rangos 


- Ordenación y mezcla externas paralelas 

• Paralelismo en consultas 

- Paralelismo en operaciones 

- Paralelismo entre operaciones 

• Paralelismo entre consultas 

• Paralelismo de datos 

• Paralelismo de E/S 

• Paralelismo entre operaciones 

- Paralelismo de encauzamiento 

- Paralelismo independiente 

• Planificación 

• Proyección paralela 

• Reunión paralela 

- Reunión por asociación dividida en paralelo 

- Reuniones con bucles anidados en paralelo 

- Reunión por división 

- Reunión con fragmentos y réplicas 

- Reunión con fragmentos y réplicas asimétricos 
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• Selección paralela 

• Sesgo 

- Sesgo de la división 

- Sesgo de ejecución 

- Sesgo de los valores de los atributos 


• Técnicas de división 

- División por asociación 

- División por rangos 

- Turno rotatorio 

• Vector de división 


EJERCICIOS 


20.1. Para cada una de las tres técnicas de división, es decir, 
por tumo rotatorio, por asociación y por rangos, dese 
un ejemplo de una consulta para la que esa técnica de 
división proporcione la respuesta más rápida. 

20.2. Al llevar a cabo una selección de rango en un atribu¬ 
to dividido por rangos es posible que sólo haga falta 
tener acceso a un disco. Descríbanse las ventajas e 
inconvenientes de esta propiedad. 

20.3. Indíquense los factores que puedan dar lugar a sesgo 
cuando se divide una relación basándose en uno de 
sus atributos utilizando: 

a. División por asociación 

b. División por rangos 

En cada uno de los casos anteriores, indíquese lo que 
se puede hacer para reducir el sesgo. 

20.4. Indíquese la forma de paralelismo (entre consultas, 
entre operaciones o en operaciones) que sea proba¬ 
blemente la más importante para cada una de las ta¬ 
reas siguientes. 

a. Incrementar la productividad de un sistema con 
muchas consultas pequeñas. 

b. Incrementar la productividad de un sistema con 
unas pocas consultas grandes cuando el número de 
discos y de procesadores es grande. 

20.5. Con el paralelismo de encauzamiento suele resultar 
adecuado llevar a cabo varias operaciones de un cau¬ 
ce en un mismo procesador, aunque haya disponibles 
muchos procesadores. 

a. Expliqúese el motivo. 

b. ¿Serían válidos los argumentos anteriores si la 
máquina utilizara una arquitectura de memoria 
compartida? Expliqúese. 

c. ¿Serían válidos los argumentos anteriores con para¬ 
lelismo independiente? (Es decir, ¿hay casos en que 
incluso si las operaciones no se encauzan y hay 
muchos procesadores disponibles sigue siendo con¬ 
veniente llevar a cabo varias operaciones en el mis¬ 
mo procesador?) 

20.6. Dese un ejemplo de una reunión, que no sea una equi- 
rreunión simple, para la que pueda utilizarse parale¬ 
lismo de particiones. ¿Qué atributos deberían utili¬ 
zarse para la división? 

20.7. Considérese el procesamiento de reuniones utilizan¬ 
do fragmentos y réplicas simétricos con división por 


rangos. ¿Cómo se puede optimizar la evaluación si la 
condición de reunión es de la forma lr.A - s.5l < k, 
donde k es una constante pequeña. Aquí, Lvl denota el 
valor absoluto de x. Una reunión con una condición 
de reunión así se denomina reunión de banda. 

20.8. Descríbase una buena manera de paralelizar lo siguien¬ 
te. 

a. La operación diferencia. 

b. La agregación utilizando la operación count. 

c. La agregación utilizando la operación count dis- 
tinct. 

d. La agregación utilizando la operación avg. 

e. La reunión externa por la izquierda, si la condición 
de reunión sólo implica igualdad. 

f. La reunión externa por la izquierda, si la condición 
de reunión implica comparaciones distintas de la 
igualdad. 

g. La reunión externa completa, si la condición de 
reunión implica comparaciones distintas de la 
igualdad. 

20.9. Recuérdese que los histogramas se utilizan para gene¬ 
rar particiones en rangos con carga equilibrada. 

a. Supóngase que se tiene un histograma en el que los 
valores varían de 1 a 100 y están divididos en 10 
rangos, 1-10, 11-20, ..., 91-100, con las frecuen¬ 
cias 15, 5, 20, 10, 10, 5, 5, 20, 5 y 5, respectiva¬ 
mente. Dese una función de división por rangos 
con carga equilibrada para dividir los valores en 
cinco particiones. 

b. Propóngase un algoritmo para procesar una divi¬ 
sión por rangos con carga equilibrada con p parti¬ 
ciones, dado un histograma de las distribuciones 
de frecuencias que contiene n rangos. 

20.10. Descríbanse las ventajas e inconvenientes de utilizar 
paralelismo de encauzamiento. 

20.11. Algunos sistemas paralelos de bases de datos guardan 
otra copia de cada elemento de los datos en discos 
conectados a un procesador diferente para evitar la 
pérdida de los datos si falla uno de los procesadores. 

a. ¿Por qué es conveniente dividir las copias de los 
elementos de los datos de un procesador entre 
varios procesadores? 

b. ¿Cuáles son las ventajas e inconvenientes de utili¬ 
zar almacenamiento RAID en lugar de guardar otra 
copia de cada elemento de datos? 
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NOTAS BIBLIOGRÁFICAS 


Los sistemas de bases de datos relaciónales comenza¬ 
ron a aparecer en el mercado en 1983; ahora lo domi¬ 
nan. A finales de los 70 y comienzos de los 80, a medi¬ 
da que el modelo relacional lograba un fundamento 
razonablemente sólido, la gente reconoció que se pue¬ 
de aprovechar un elevado nivel de paralelismo en los 
operadores de relación y tienen buenas propiedades de 
flujo de datos. Se lanzaron en rápida sucesión un siste¬ 
ma comercial, Teradata, y varios proyectos de investi¬ 
gación, como GRACE (Kitsuregawa et al. [1983], Fus- 
ífimi et al. [1986]), GAMMA (DeWitt et al. [1986, 
1990]) y Bubba (Boral et al. [1990]). Los investigado¬ 
res utilizaron estos sistemas paralelos de bases de datos 
para estudiar la viabilidad de la ejecución en paralelo 
de los operadores relaciónales. Posteriormente, a fina¬ 
les de los 80 y en los 90, varias compañías más -como 
Tándem, Oracle, Sybase, Informix y Red-Brick (ahora 
parte de Informix, que a su vez es parte de IBM)— han 
entrado en el mercado de bases de datos paralelas. Los 
proyectos de investigación en el mundo académico in¬ 
cluyen XPRS (Stonebraker et al. [1989]) y Volcano 
(Graefe [1990]). 

El bloqueo en las bases de datos paralelas se discu¬ 
te en Joshi [1991] y en Mohán y Narang [1991, 1992b]. 
Los protocolos sobre coherencia de caché para los sis¬ 
temas paralelos de bases de datos se discuten en Dias 
et al. [1989], Mohán y Narang [1991], Mohán y Narang 


[1992] y en Rahm [1993]. Carey et al [1991] discute los 
asuntos de caché en sistemas cliente-servidor. El para¬ 
lelismo y la recuperación en sistemas de bases de datos 
se discuten en Bayer et al. [1980]. 

Graefe [1993] presenta una excelente visión general 
del procesamiento de consultas, incluyendo el procesa¬ 
miento de consultas en paralelo. La ordenación en para¬ 
lelo se discute en DeWitt et al. [1992]. Los algoritmos 
de reuniones en paralelo se describen en Nakayama et 
al. [1984], Kitsuregawa et al. [1983] y Richardson et al. 
[1987], Schneider y DeWitt [1989], Kitsuregawa y Oga- 
wa [1990], Lin et al. [1994] y Wilschut et al. [1995], 
entre otros trabajos. Los algoritmos para la reunión en 
paralelo para arquitecturas de memoria compartida se 
describen en Tsukuda et al. [1992], Deshpande y Lar- 
son [1992] y Shatdal y Naughton [1993]. 

El tratamiento del sesgo en las reuniones en paralelo 
se describe en Walton et al. [ 1991 ], Wolf [ 1991 ] y DeWitt 
et al. [1992]. Las técnicas de muestreo para bases de datos 
paralelas se describen en Seshadri y Naughton [1992] y 
Ganguly et al. [1996]. Graefe [1990] y Graefe [1993] 
defendieron el modelo del operador de intercambio. 

Las técnicas de optimización de las consultas en para¬ 
lelo se describen en H. Lu y Tan [1991], Hong y Sto¬ 
nebraker [1991], Ganguly et al. [1992], Lanzelotte et 
al. [1993], Hasan y Motwani [1995] y Jhingran et al. 
[1997], 
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PARTE 


VII 


OTROS TEMAS 


E l Capítulo 21 trata varios aspectos sobre la creación y el mantenimiento 
de aplicaciones y de la administración de sistemas de bases de datos. El 
capítulo describe en primer lugar el modo de implementar las interfaces 
de usuario, en especial las interfaces basadas en Web. Otros aspectos como el 
ajuste del rendimiento (para mejorar la velocidad de las aplicaciones), la nor¬ 
malización en el comercio electrónico y el modo de tratar los sistemas here¬ 
dados se tratan también en este capítulo. 

El Capítulo 22 describe varios avances recientes en la realización de consul¬ 
tas y la recuperación de la información. En primer lugar trata las extensiones 
de SQL para dar soporte a nuevos tipos de consultas, en especial a las consul¬ 
tas que suelen formular los analistas de datos. A continuación trata el almace¬ 
naje de datos, en el que los datos generados por las diferentes partes de una 
organización se reúnen de manera centralizada. El capítulo describe luego la 
recopilación de datos, que pretende hallar estructuras de diversas formas com¬ 
plejas en grandes volúmenes de datos. Finalmente, el capítulo describe la recu¬ 
peración de la información, que trata de las técnicas para consultar conjuntos 
de documentos de texto, como las páginas Web, para hallar los documentos de 
interés. 

El Capítulo 22 describe los tipos de datos, como los datos temporales, los 
espaciales y los multimedia, y los aspectos del almacenamiento de dichos datos 
en las bases de datos. Las aplicaciones como la informática móvil y sus cone¬ 
xiones con las bases de datos también se describen en este capítulo. 

Finalmente, el Capítulo 23 describe varias técnicas avanzadas de procesa¬ 
miento de transacciones, incluidos los monitores de procesamiento de tran¬ 
sacciones, los flujos de trabajo transaccionales, las transacciones de larga 
duración y las transacciones entre varias bases de datos. 


CAPÍTULO 



DESARROLLO DE APLICACIONES 
Y ADMINISTRACIÓN 


C asi todo el uso de las bases de datos se produce desde los programas de aplicaciones. A su 
vez, casi toda la interacción con los usuarios con las bases de datos es indirecta, median¬ 
te los programas de aplicaciones. No resulta sorprendente, por tanto, que los sistemas 
de bases de datos lleven mucho tiempo soportando herramientas como los generadores de for¬ 
mularios y de interfaces gráficas de usuario, que ayudan a lograr el desarrollo rápido de apli¬ 
caciones que actúan de interfaz con los usuarios. En los últimos años la Web se ha transforma¬ 
do en la interfaz de usuario con las bases de datos más utilizada. 

Una vez creada una aplicación suele descubrirse que se ejecuta más lenta de lo que desea¬ 
ban los diseñadores o que maneja menos transacciones por segundo de lo necesario. Se puede 
hacer que las aplicaciones se ejecuten significativamente más rápido mediante el ajuste del ren¬ 
dimiento, que consiste en hallar y eliminar los cuellos de botella y en añadir el hardware ade¬ 
cuado, como puede ser memoria o discos. Los índices de calidad ayudan a caracterizar el ren¬ 
dimiento de los sistemas de bases de datos. 

Las normas son muy importantes para el desarrollo de las aplicaciones, especialmente en la 
época de Internet, dado que éstas necesitan comunicarse entre sí para llevar a cabo tareas úti¬ 
les. Se han propuesto varias normas que afectan al desarrollo de las aplicaciones de bases de 
datos. 

El comercio electrónico se está convirtiendo en parte integral del modo en que se adquieren 
bienes y servicios y las bases de datos desempeñan un papel importante en ese dominio. 

Los sistemas heredados son sistemas basados en tecnología de generaciones anteriores. Sue¬ 
len hallarse en el núcleo de las organizaciones y ejecutan aplicaciones con misiones críticas. 
Se describen aspectos del establecimiento de interfaces con los sistemas heredados y el modo 
en que pueden sustituirse por otros sistemas. 


21.1. INTERFACES WEB PARA BASES DE DATOS 


La World Wide Web (Web, para abreviar) es un siste¬ 
ma distribuido de información basado en hipertexto. 
Las interfaces Web con las bases de datos se han vuel¬ 
to muy importantes. Tras describir varios motivos para 
establecer interfaces con la Web (Apartado 21.1.1) se 
ofrece un resumen de la tecnología Web (Apartado 

21.1.2) y se estudian los servidores Web (Apartado 

21.1.3) y se describen algunas técnicas de primera línea 
para la creación de interfaces Web con bases de datos, 
mediante servlets y lenguajes de guiones del lado del 
servidor (Apartados 21.1.4 y 21.1.5). En el Apartado 
21.1.6 se describen técnicas para mejorar el rendimiento. 

21.1.1. Motivación 

La Web se ha vuelto importante como frontal para las 
bases de datos por varios motivos: los navegadores Web 
ofrecen un frontal universal para la información facili¬ 
tada por los dorsales ubicados en cualquier parte del 
mundo. El frontal puede ejecutarse en cualquier siste¬ 
ma informático y no hace falta que el usuario descar¬ 


gue software específico para que tenga acceso a la infor¬ 
mación. Además, hoy en día casi todos los que pueden 
permitírselo tienen acceso a la Web. 

Con el crecimiento de los servicios de información 
y del comercio electrónico en la Web, las bases de datos 
empleadas para los servicios de información, el ayuda 
a la toma de decisiones y el procesamiento de tran¬ 
sacciones deben estar conectadas a la Web. La inter¬ 
faz de los formularios HTML resulta conveniente para 
el procesamiento de las transacciones. El usuario pue¬ 
de rellenar los detalles de un formulario de pedido y 
pulsar un botón de envío para remitir un mensaje al 
servidor, el cual ejecuta un programa de aplicación 
correspondiente al formulario de pedido y esta acción, 
a su vez, ejecutará las transacciones en una base de 
datos en el sitio del servidor. El servidor da formato a 
los resultados de la transacción y se los devuelve al 
usuario. 

Otro motivo para el uso de interfaces entre las bases 
de datos y la Web es que la presentación exclusiva de 
documentos estáticos (fijos) en un sitio Web presenta 
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algunas limitaciones, aunque el usuario no realice nin¬ 
guna consulta ni procese ninguna transacción: 

• Los documentos Web fijos no permiten que lo que 
se muestre se adapte al usuario. Por ejemplo, pue¬ 
de que un periódico desee personalizar su aspec¬ 
to para cada usuario, para destacar los artículos 
informativos que con mayor probabilidad intere¬ 
sen al usuario. 

• Cuando se actualizan los datos de la compañía, los 
documentos de la Web se quedan obsoletos si no se 
actualizan de manera simultánea. El problema se 
hace más grave si varios documentos de la Web repli¬ 
can datos importantes y hay que actualizarlos todos. 

Estos problemas pueden resolverse mediante la gene¬ 
ración dinámica de los documentos de la Web a partir 
de una base de datos. Cuando se solicita un documento 
se ejecuta un programa en el sitio del servidor, que a su 
vez ejecuta consultas en una base de datos y genera el 
documento solicitado de acuerdo con los resultados de 
las consultas. Siempre que se actualizan datos importan¬ 
tes de la base de datos los documentos generados se actua¬ 
lizan de manera automática. El documento generado tam¬ 
bién puede personalizarse para el usuario de acuerdo con 
la información del usuario guardada en la base de datos. 

Las interfaces Web ofrecen ventajas atrayentes inclu¬ 
so para aplicaciones de bases de datos que sólo se uti¬ 
lizan dentro de una organización. La norma lenguaje 
de marcas de hipertexto (HyperText Markup Lan- 
guage, HTML) permite que el texto reciba formato de 
manera ordenada y que se destaque la información 
importante. Los hipervínculos, que son enlaces con 
otros documentos, pueden asociarse con regiones de los 
datos mostrados. Al pulsar en un hipervínculo se cap¬ 
tura el documento vinculado y se muestra. Los hiper¬ 
vínculos resultan muy útiles para explorar datos, lo que 
permite a los usuarios obtener más detalles de las par¬ 
tes de los datos que prefieran. 

Finalmente, los navegadores de hoy en día pueden 
capturar programas junto con los documentos E1TML, y 
ejecutarlos en el navegador, en modo seguro, es decir, 
sin dañar los datos de la computadora del usuario. Los 
programas pueden escribirse en lenguajes de guiones del 
lado del cliente, como JavaScript, o ser applets escritas 
en el lenguaje Java. Estos programas permiten la crea¬ 
ción de interfaces de usuario sofisticadas, más de lo que 
es posible únicamente con E1TML, interfaces que pue¬ 
den utilizarse sin descargar ni instalar ningún software. 
Por ello, las interfaces Web resultan potentes y atracti¬ 
vas visualmente, y es posible que eclipsen las interfaces 
específicas salvo para una pequeña clase de usuarios. 

21.1.2. Fundamentos de la Web 

En este apartado se va a repasar parte de la tecnología 
básica tras la World Wide Web, para los lectores que no 
estén familiarizados con ella. 


21.1.2.1. Los localizadores uniformes 
de recursos 

Un localizador uniforme de recursos (Uniform 
Resource Locator, URL) es un nombre globalmente 
único para cada documento al que se puede tener acce¬ 
so en la Web. Un ejemplo de URL es 

http://www.bell-labs.com/topic/books/db-book 

La primera parte del URL indica el modo en que se 
puede tener acceso al documento: http indica que se 
puede tener acceso al documento mediante el protoco¬ 
lo de transferencia de hipertexto (HyperText Transfer 
Protocol, HTTP), que es un protocolo para transferir 
documentos HTML. La segunda parte da el nombre úni¬ 
co de una máquina que tiene un servidor Web. El resto 
del URL es el nombre del camino hasta el archivo en la 
máquina, u otro identificador único del documento den¬ 
tro de la máquina. 

Muchos datos de la Web se generan de manera diná¬ 
mica. Un URL puede contener el identificador de un 
programa ubicado en la máquina servidora Web, así 
como argumentos que hay que darle al programa. Un 
ejemplo de URL de este tipo es 

http://www.google.com/search?q=silberschatz 

que dice que el programa search en el servidor 
www.google.com se debe ejecutar con el argumento 
q=silberschatz. El programa se ejecuta, utilizando los 
argumentos dados, y devuelve un documento HTML, 
que se envía al frontal. 

21.1.2.2. El lenguaje de marcas de hipertexto 

La Figura 21.1 es un ejemplo de origen de un docu¬ 
mento HTML. La Figura 21.2 muestra la imagen que 
crea este documento. 


<html> 

<body> 

<table BORDER C0LS=3> 

<tr> <td>C-101 </td> <td>Centro</td> <td>500</td> </tr> 

<tr> <td>C-102</td> <td>Navacerrada</td> <td>400</td> </tr> 
<tr> <td>C-201 </td> <td>Galapagar </td> <td>900</td> </tr> 
</table> 

<center> La <¡>relación</¡> cuenta </center> 

<form action=”BankQuery” method=get> 

Seleccione cuenta/préstamo e introduzca el número <br> 
<select name=”tipo”> 

coption value=”cuenta” seleccionada>Cuenta 
coption value=”préstamo”> Préstamo 
</select> 

cinput type=text size=5 name=”número”> 
cinput type=submit value=”Enviar”> 

</body> 

</html> 

FIGURA 21.1. Texto fuente HTML. 
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C-101 

Centro 

500 

C—102 

Navacerrada 

400 

C—201 

Galapagar 

900 


La relación cuenta 


Seleccione cuenta/préstamo e introduzca el número 
Cuenta - 


envrar 


FIGURA 21.2. Visualización del texto fuente HTML de la 
Figura 21.1. 


Las figuras muestran el modo en que HTML puede 
mostrar una tabla y un formulario sencillo que permite 
que los usuarios seleccionen el tipo (cuenta o préstamo) 
de un menú e introducir un número en un cuadro de tex¬ 
to. HTML también soporta otros tipos de entrada. Al 
pulsar en el botón de envío se hace que el programa 
BankQuery (especificado en el campo form actlon) se 
ejecute con los valores proporcionados por el usuario 
para los argumentos type y number (especificados en 
los campos select e input). El programa genera un docu¬ 
mento HTML, que se devuelve al usuario y se le mues¬ 
tra; se verá el modo de crear estos programas en los 
Apartados 21.1.3, 21.1.4 y 21.1.5. 

HTML soporta hojas de estilo, que pueden modifi¬ 
car las definiciones predeterminadas del modo en que 
se muestran las estructuras de formato de HTML, así 
como otros atributos de exhibición como el color de 
fondo de la página. La norma hojas de estilo en casca¬ 
da (cascading stylesheet, css) permite que la misma hoja 
de estilo se utilice para varios documentos HTML, lo 
que da un aspecto uniforme a todas las páginas del sitio 
Web. 

21.1.2.3. Guiones del lado del cliente y applets 

La inclusión de código de programa en los documentos 
permite que las páginas Web sean activas y ejecuten 
actividades como la animación ejecutando programas 
en el sitio local, en lugar de presentar simplemente tex¬ 
tos pasivos y gráficos. El uso principal de estos pro¬ 
gramas es la interacción flexible con el usuario, más allá 
de la limitada capacidad de interacción proporcionada 
por HTML y por los formularios HTML. Además, la 
ejecución de programas en el sitio del cliente acelera 
mucho la interacción, en comparación con tener que 
enviar cada interacción al sitio del servidor para su pro¬ 
cesamiento. 

Un riesgo de dar soporte a esos programas es que, si 
el diseño del sistema no se realiza con cuidado, el códi¬ 
go de programa incluido en la página Web (o, de modo 
equivalente, en un mensaje de correo electrónico) pue¬ 
de realizar acciones malévolas en la computadora del 
usuario. Las acciones malévolas pueden variar desde la 
lectura de información privada o la eliminación o la 
modificación de información de la computadora hasta 


la toma del control de la computadora y la difusión del 
código a otras computadoras (por correo electrónico, 
por ejemplo). En los últimos años varios viras de correo 
electrónico se han difundido ampliamente de este modo. 

El lenguaje Java se ha hecho muy popular porque 
proporciona un modo seguro de ejecutar los programas 
en las computadoras de los usuarios. El código Java pue¬ 
de compilarse en «código de bytes» independiente de 
la plataforma que puede ejecutarse en cualquier explo¬ 
rador que soporte Java. A diferencia de los programas 
locales, los programas de Java ( applets ) descargados 
como parte de una página Web carecen de autoridad 
para llevar a cabo acciones que puedan resultar des¬ 
tructivas. Se les permite mostrar datos en la pantalla o 
establecer una conexión de red para obtener más infor¬ 
mación con el servidor desde el que se ha descargado 
la página Web. Sin embargo, no se les permite el acce¬ 
so a los archivos locales, ejecutar programas del siste¬ 
ma ni establecer conexiones de red con otras computa¬ 
doras. 

Aunque Java es un lenguaje de programación com¬ 
pleto, hay lenguajes más sencillos, denominados len¬ 
guajes de guiones, que pueden enriquecer la interac¬ 
ción con el usuario, mientras ofrecen la misma 
protección que Java. Estos lenguajes proporcionan 
estructuras que pueden incluirse en los documentos de 
HTML. Los lenguajes de guiones del lado del clien¬ 
te son lenguajes diseñados para ejecutarse en el explo¬ 
rador Web del cliente. De entre ellos, el lenguaje JavaS¬ 
cript es, con mucho, el más utilizado. También existen 
lenguajes de guiones con finalidades especiales para 
tareas especializadas como la animación (por ejemplo, 
Flash y Shockwave de Macromedia) y el modelado tri¬ 
dimensional (lenguaje de marcas de realidad virtual, 
Virtual Reality Markup Language, VRML). Los len¬ 
guajes de guiones también pueden utilizarse en el lado 
del servidor, como se verá más adelante. 

21.1.3. Los servidores Web y las sesiones 

Los servidores Web son programas que se ejecutan en 
la máquina servidora, que aceptan las solicitudes de los 
exploradores Web y devuelven los resultados en forma 
de documentos HTML. El explorador y el servidor Web 
se comunican mediante un protocolo denominado pro¬ 
tocolo de transferencia de hipertexto (HyperText 
Transfer Protocol, HTTP). HTTP proporciona carac¬ 
terísticas potentes, más allá de la mera transferencia de 
documentos. La característica más importante es la posi¬ 
bilidad de ejecutar programas con los argumentos pro¬ 
porcionados por el usuario y de devolver los resultados 
como documentos HTML. 

En consecuencia, los servidores Web pueden actuar 
con facilidad como intermediarios para ofrecer acceso 
a diversos servicios de información. Se pueden crear 
servicios nuevos mediante la creación e instalación de 
programas de aplicaciones que ofrezcan los servicios. 
La norma interfaz de pasarela común (common gate- 
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way interface, CGI) define el modo en que el servidor 
Web se comunica con los programas de las aplicacio¬ 
nes. Los programas de las aplicaciones suelen comuni¬ 
carse con servidores de bases de datos, mediante ODBC, 
JDBC u otros protocolos, con objeto de obtener o guar¬ 
dar datos. 

La Figura 21.3 muestra un servicio Web que emplea 
una arquitectura de tres capas, con un servidor Web, un 
servidor de aplicaciones y un servidor de bases de datos. 
El empleo de varios niveles de servidores incrementa 
la sobrecarga del sistema; la interfaz CGI inicia un pro¬ 
ceso nuevo para atender cada solicitud, lo que supone 
una sobrecarga todavía mayor. 

Por tanto, la mayor parte de los servicios Web de hoy 
en día utilizan una arquitectura Web de dos capas, en la 
que el programa de la aplicación se ejecuta en el servi¬ 
dor Web, como en la Figura 21.4. En los apartados 
siguientes se estudiarán con más detalle los sistemas 
basados en arquitectura de dos capas. 

Hay que tener en cuenta que no existe una conexión 
continua entre el cliente y el servidor. Por el contrario, 
cuando un usuario inicia una sesión en una computa¬ 
dora o se conecta con un servidor ODBC o JDBC, se 
crea una sesión y en el servidor y en el cliente, se con¬ 
serva la información de la sesión hasta que ésta con¬ 
cluya (información tal como si se autentificó al usuario 
mediante contraseña o las opciones de sesión definidas 
por el usuario). El motivo de que HTTP sea sin cone¬ 
xión es que la mayor parte de las computadoras pre¬ 
sentan límites en el número de conexiones simultáneas 
que pueden aceptar; y si gran número de sitios de la Web 
abren conexiones, se podría superar ese límite y dene¬ 
garse el servicio a otros posteriores. Con un servicio sin 
conexión, ésta se interrumpe en cuanto se satisface una 
solicitud, lo que deja las conexiones disponibles para 
otras solicitudes. 

La mayor parte de los servicios de información nece¬ 
sitan información sobre las sesiones. Por ejemplo, los 


servicios suelen restringir el acceso a la información y, 
por tanto, necesitan autentificar a los usuarios. La auten¬ 
ticación debe hacerse una vez por sesión, y las interac¬ 
ciones posteriores de la sesión no deben exigir que se 
repita la autenticación. 

Para crear la vista de estas sesiones hay que guardar 
en el cliente información adicional, y devolverla con 
cada solicitud de la sesión, para que el servidor identi¬ 
fique que la solicitud forma parte de la sesión del usua¬ 
rio. En el servidor también hay que guardar informa¬ 
ción adicional sobre la sesión. 

Esta información adicional se conserva en el clien¬ 
te en forma de cookie; una cookie no es más que un 
pequeño fragmento de texto que contiene información 
de identificación. El servidor envía una cookie al clien¬ 
te tras la autenticación, y también guarda una copia de 
modo local. Las cookies enviadas a clientes diferentes 
contienen texto de identificación diferente. El explora¬ 
dor envía las cookies de manera automática en poste¬ 
riores solicitudes de documentos al mismo servidor. 
Mediante la comparación de la cookie con las cookies 
guardadas de manera local en el servidor, éste puede 
identificar la solicitud como integrante de una sesión 
activa. Las cookies también pueden utilizarse para guar¬ 
dar las preferencias de los usuarios y emplearlas cuan¬ 
do el servidor responda a una solicitud. Las cookies pue¬ 
den guardarse en el explorador de manera permanente; 
identifican al usuario en visitas posteriores al mismo 
sitio, sin que haya que escribir ninguna identificación. 

21.1.4. Servlets 

En la arquitectura Web de dos capas las aplicaciones se 
ejecutan como parte del propio servidor Web. Un modo 
de implementar esta arquitectura es cargar los progra¬ 
mas Java con el servidor Web. La especificación serv- 
let de Java define una interfaz de programación de apli¬ 
caciones para la comunicación entre el servidor Web y 



FIGURA 21.3. Arquitectura de tres capas. 
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los programas de aplicaciones. La palabra servlet tam¬ 
bién hace referencia a un programa Java que implementa 
la interfaz servlet. El programa se carga en el servidor 
Web cuando éste se inicia o cuando el servidor recibe 
una solicitud Web para ejecutar la aplicación servlet. La 
Figura 21.5 es un ejemplo de código servlet para imple- 
mentar el formulario de la Figura 21.1. 

El servlet se denomina BankQueryServIet, mientras 
que el formulario especifica que action=«Bank-Query». 
Se debe indicar al servidor Web que este servlet se va 
a utilizar para tratar las solicitudes para BankQuery. 

El ejemplo dará una idea del modo en que se emplean 
los servlets. Para obtener los detalles necesarios para 
crear una aplicación servlet se puede consultar un libro 
sobre servlets o leer la documentación en línea referente 
a servlets que forma parte de la documentación de Java 
que facilita Sun. Véanse las notas bibliográficas para 
obtener referencias de estas fuentes. 

El formulario especifica que se emplea el mecanis¬ 
mo HTTP get para transmitir los parámetros (post es el 
otro mecanismo más utilizado). Así se invoca el méto¬ 
do doGetQ del servlet, que se define en el código. Cada 
solicitud da lugar a una nueva hebra en la que se eje¬ 
cuta la llamada, por lo que se pueden tratar en paralelo 
varias solicitudes. 

Los valores de los menús del formulario y de los 
campos de entrada de la página Web, así como las coo- 
kies, pasan por un objeto de la clase HttpServIetRequest 
que se crea para la solicitud, y la respuesta a la solici¬ 
tud pasa por un objeto de la clase HttpServIet-Respon- 
se 1 . 

El código del método doGet() del ejemplo extrae los 
valores del tipo y del número del parámetro mediante 
request.getParameter(), y los utiliza para realizar una 
consulta a la base de datos. El código empleado para 


tener acceso a la base de datos no se muestra; hay que 
consultar el Apartado 4.13.2 para conseguir detalles del 
modo de empleo de JDBC para tener acceso a las bases 
de datos. El sistema devuelve el resultado de la consulta 
al solicitante imprimiéndolos en formato HTML en Http- 
Servlet-Response result. 

La API del servlet ofrece un método conveniente de 
creación de sesiones. Al llamar al método getSes- 
sion(true) de la clase HttpServIetRequest se crea un obje¬ 
to nuevo del tipo HttpSession si se trata de la primera 
solicitud de ese cliente; el argumento true indica que 
hay que crear una sesión si se trata de una solicitud nue¬ 
va. El método devuelve un objeto ya existente si ya se 
había creado para esa sesión del explorador. Interna¬ 
mente se utilizan cookies para reconocer que una soli¬ 
citud proviene de la misma sesión del explorador que 
otra anterior. El código de servlet puede guardarse y 
buscar parejas (nombre-atributo, valor) en el objeto 
HttpSession, para conservar el estado para varias soli¬ 
citudes. Por ejemplo, puede que la primera solicitud de 
una sesión solicite la identidad y la contraseña del usua¬ 
rio y guarde la identidad del usuario en el objeto sesión. 
En solicitudes posteriores desde esa sesión del navega¬ 
dor la identidad del usuario se hallará en el objeto sesión. 

La visualización de los resultados de las consultas 
es una labor común de muchas aplicaciones de bases de 
datos. Se puede crear una función genérica que tome 
como argumento cualquier conjunto de resultados de 
JDBC y muestre adecuadamente las tupias en el con¬ 
junto de resultados. Las llamadas a los metadatos de 
JDBC pueden utilizarse para buscar informaciones en 
el resultado de la consulta como el número de colum¬ 
nas y el nombre y el tipo de las columnas; esta infor¬ 
mación se utiliza luego para imprimir el resultado de la 
consulta. 


1 La interfaz servlet también puede soportar solicitudes que no sean 
HTTP, aunque los ejemplos de este libro sólo utilicen HTTP. 
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public class BankQueryServIet extends HttpServIet { 

public void doGet(HttpServletRequest request, HttpServIetResponse result) 
throws ServIetException, lOException 

{ 

String type = request.getParameter(“type”); 

String number = request.getParameterfnumber”); 

... código para buscar el saldo del préstamo/cuenta ... 

... empleo de JDBC para comunicarse con la base de datos ... 

... se da por supuesto que el valor se guarda en la variable balance ... 

result.setContentType(“text/html”); 

PrintWnter out = result.getWriter(); 

out.println(“<HEAD><TITLE> Resultado de la consulta</TITLEx/HEAD>”); 
out.println(“<BODY>”); 

out.prlntln(“Saldo a ” + type + number + “ = ” + balance); 

out.println(“</BODY>”); 

out.close(); 

} 

} 

FIGURA 21.5. Ejemplo de código servlet. 


21.1.5. Guiones del lado del servidor 

La escritura incluso de una mera aplicación Web en un 
lenguaje de programación como Java o C supone una 
tarea que consume bastante tiempo y necesita muchas 
líneas de código y programadores familiarizados con 
las complejidades del lenguaje. Un enfoque alternati¬ 
vo, el de los guiones del lado del servidor, ofrece un 
método mucho más sencillo de creación de muchas apli¬ 
caciones. Los lenguajes de guiones ofrecen estructuras 
que pueden incluirse en los documentos HTML. En los 
guiones del lado del servidor, antes de entregar una pági¬ 
na Web, el servidor ejecuta las secuencias incluidas en 
el contenido HTML de la página. Cada secuencia, al 
ejecutarse, puede generar texto que se añade a la pági¬ 
na (o que incluso puede eliminar contenido de la pági¬ 
na). El código fuente de los guiones se elimina de la 
página, de modo que puede que el cliente ni siquiera se 
dé cuenta de que la página contenía originalmente códi¬ 
go. Puede que la secuencia de comandos ejecutada con¬ 
tenga código SQL que se ejecute en una base de datos. 

En los últimos años han aparecido varios lenguajes 
de guiones. Entre ellos están Server-Side JavaScript de 
Netscape, JScript de Microsoft, JavaServer Pages (JSP) 
de Sun, el preprocesador de hipertexto PHP (PHP Hyper- 
text Preprocessor, PHP), el lenguaje de marcas Cold- 
Fusion de ColdFusion (ColdFusion’s ColdFusion Mar- 
kup Language, CFML) y DTML de Zope. De hecho, 
incluso es posible incluir en las páginas HTML código 
escrito en lenguajes de guiones más antiguos como 
VBScript, Perl y Python. Por ejemplo, Active Server 
Pages (ASP) de Microsoft soporta VBScript y JScript 
incorporados. Otros enfoques han extendido el softwa¬ 
re para la escritura de informes, desarrollado original¬ 
mente para la generación de informes imprimibles, para 
generar informes HTML. También soporta los formu¬ 
larios HTML para la obtención de los valores de los 
parámetros que se utilizan en las consultas incrustadas 
en los informes. 


Claramente, hay muchas opciones entre las que esco¬ 
ger. Todas soportan características similares, pero se 
diferencian en el estilo de programación y en la facili¬ 
dad con que se pueden crear aplicaciones sencillas. 

21.1.6. Mejora del rendimiento 

Miles de millones de personas de todo el globo pueden 
tener acceso a los sitios Web, con tasas de millares de 
solicitudes por segundo, o incluso mayores, en el caso 
de los sitios más populares. Asegurarse de que las soli¬ 
citudes se atiendan con tiempos de respuesta bajos supo¬ 
ne un importante desafío para los desarrolladores de los 
sitios Web. 

Se emplean técnicas de almacenamiento caché de 
varios tipos para aprovechar las características comu¬ 
nes de las diversas transacciones. Por ejemplo, supón¬ 
gase que el código de la aplicación para la atención de 
cada solicitud necesita contactar con una base de datos 
mediante JDBC. La creación de una nueva conexión 
JDBC puede tardar varios milisegundos, por lo que la 
apertura de una conexión nueva para cada solicitud no 
es una buena idea si hay que soportar tasas de transac¬ 
ción muy elevadas. Muchas aplicaciones crean un fon¬ 
do de conexiones JDBC abiertas y cada solicitud utili¬ 
za una de las conexiones de ese fondo. 

Puede que muchas solicitudes den por resultado exac¬ 
tamente la misma consulta que se ejecutará en la base 
de datos. El coste de la comunicación con la base de 
datos puede reducirse enormemente guardando en la 
caché los resultados de consultas anteriores y volvien¬ 
do a utilizarlas, en tanto en cuanto no haya cambiado 
en la base de datos el resultado de la consulta. Algunos 
servidores Web soportan este almacenamiento en la 
caché de los resultados de las consultas. 

Se pueden reducir aún más los costes guardando en 
la caché la página Web final que se envía en respuesta 
a una consulta. Si llega una consulta nueva exactamen¬ 
te con los mismos parámetros que una consulta anterior 
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y la página Web resultante se halla en la caché, puede 
volver a utilizarse, lo que evita el coste de volver a calcu¬ 
lar la página. 

Los resultados de las consultas y las páginas Web 
guardados en la caché son modalidades de vistas mate¬ 
rializadas. Si la base de datos subyacente se modifica, 
pueden descartarse o volver a calcularse o, incluso, 


actualizarse de modo incremental, como en el mante¬ 
nimiento de las vistas materializadas (Apartado 14.5). 
Por ejemplo, el servidor Web de IBM que se empleó en 
los Juegos Olímpicos de 2000 puede realizar el segui¬ 
miento de los datos de los que depende una página Web 
guardada en la caché y volver a calcular la página si se 
modifican esos datos. 


21.2. AJUSTE DEL RENDIMIENTO 


El ajuste del rendimiento de un sistema implica el ajus¬ 
te de varios parámetros y opciones de diseño para mejo¬ 
rar su rendimiento para una aplicación concreta. Varios 
aspectos del diseño de los sistemas de bases de datos 
(que van desde aspectos de alto nivel como el esquema 
y el diseño de las transacciones hasta parámetros de las 
bases de datos como los tamaños de la memoria inter¬ 
media o aspectos del hardware como el número de dis¬ 
cos) afectan al rendimiento de las aplicaciones. Cada 
uno de estos aspectos puede ajustarse de modo que se 
mejore el rendimiento. 

21.2.1. Localización de los cuellos de botella 

El rendimiento de la mayor parte de los sistemas (al 
menos, antes de ajustarlos) suele quedar limitado prin¬ 
cipalmente por el que presenta un componente o unos 
pocos, denominados cuellos de botella. Por ejemplo, 
puede que un programa pase el 80 por ciento del tiem¬ 
po en un pequeño bucle ubicado en las profundidades 
del código y el 20 por ciento restante del tiempo en el 
resto del código; ese pequeño bucle es, pues, un cuello 
de botella. La mejora del rendimiento de un componente 
que no sea un cuello de botella hace poco para mejorar 
la velocidad global del sistema; en este ejemplo, la mejo¬ 
ra de la velocidad del resto del código no puede llevar 
a más de un 20 por ciento de mejora global, mientras 
que la mejora de la velocidad del bucle cuello de bote¬ 
lla puede lograr una mejora de casi el 80 por ciento glo¬ 
bal, en el mejor de los casos. 

Por tanto, al ajustar un sistema, primero hay que 
intentar descubrir los cuellos de botella y luego elimi¬ 
narlos mejorando el rendimiento de los componentes 
que los generan. Cuando se elimina un cuello de bote¬ 
lla puede ocurrir que otro componente se transforme en 
cuello de botella. En los sistemas bien equilibrados nin¬ 
gún componente aislado constituye un cuello de bote¬ 
lla. Si el sistema contiene cuellos de botella se infrau- 
tilizan los componentes que no forman parte de los 
cuellos de botella y quizás pudieran haberse sustituido 
por componentes más económicos de menores presta¬ 
ciones. 

En los programas sencillos el tiempo pasado en cada 
zona del código determina el tiempo global de ejecu¬ 
ción. No obstante, los sistemas de bases de datos son 


mucho más complejos y pueden modelarse como sis¬ 
temas de colas. Cada transacción necesita varios ser¬ 
vicios del sistema de bases de datos, comenzando por 
la entrada en los procesos del servidor, las lecturas de 
disco durante la ejecución, los ciclos de la CPU y los 
bloqueos para el control de la concurrencia. Cada uno 
de estos servicios tiene asociada una cola, y puede que 
las transacciones pequeñas pasen la mayor parte del 
tiempo esperando en las colas —especialmente en las 
colas de E/S de los discos— en lugar de ejecutando códi¬ 
go. La Figura 21.6 muestra algunas de las colas de los 
sistemas de bases de datos. 

Como consecuencia de las numerosas colas de la 
base de datos, los cuellos de botella de los sistemas de 
bases de datos suelen manifestarse en forma de largas 
colas para un servicio determinado o, de modo equiva¬ 
lente, en elevados índices de utilización de un servicio 
concreto. Si las solicitudes se espacian de manera exac¬ 
tamente uniforme, y el tiempo para atender una solici¬ 
tud es menor o igual que el tiempo antes de que llegue 
la siguiente solicitud, cada solicitud hallará el recurso 
sin utilizar y podrá iniciar la ejecución de manera inme¬ 
diata, sin esperar. Por desgracia, la llegada de las soli¬ 
citudes en los sistemas de bases de datos nunca es tan 
uniforme, más bien aleatoria. 

Si un recurso, como puede ser un disco, tiene un índi¬ 
ce de utilización bajo, cuando se realiza una solicitud 
es probable que ese recurso esté sin utilizar, en cuyo 
caso el tiempo de espera de la solicitud será cero. Supo¬ 
niendo llegadas distribuidas de forma aleatoria unifor¬ 
me, la longitud de la cola (y, en consecuencia, el tiem¬ 
po de espera) aumentará de manera exponencial con la 
utilización; a medida que la utilización se aproxime al 
ciento por ciento, la longitud de la cola aumentará abrup¬ 
tamente, lo que dará lugar a tiempos de espera excesi¬ 
vamente elevados. La utilización de los recursos debe 
mantenerse lo suficientemente baja como para que la 
longitud de la cola sea corta. Como indicativo, las uti¬ 
lizaciones cercanas al 70 por ciento se consideran bue¬ 
nas, y las utilizaciones superiores al 90 por ciento se 
consideran excesivas, dado que generan retrasos signi¬ 
ficativos. Para aprender más sobre la teoría de los sis¬ 
temas de colas, generalmente conocida como teoría de 
colas, se pueden consultar las referencias citadas en las 
notas bibliográficas. 
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FIGURA 21.6. Colas de un sistema de bases de datos. 


21.2.2. Parámetros ajustables 

Los administradores de bases de datos pueden ajustar 
los sistemas de bases de datos en tres niveles. El nivel 
inferior es el nivel de hardware. Las opciones para el 
ajuste de los sistemas en este nivel incluyen añadir dis¬ 
cos o usar sistemas RAID (si la E/S de disco constitu¬ 
ye un cuello de botella), añadir más memoria si el tama¬ 
ño de la memoria intermedia de disco constituye un 
cuello de botella o aumentar la velocidad del proce¬ 
sador si el empleo de la CPU constituye un cuello de 
botella. 

El segundo nivel consiste en los parámetros de los 
sistemas de bases de datos, como el tamaño de la memo¬ 
ria intermedia y los intervalos de puntos de revisión. El 
conjunto exacto de los parámetros de los sistemas de 
bases de datos que pueden ajustarse depende de cada 
sistema concreto de bases de datos. La mayor parte de 
los manuales de los sistemas de bases de datos propor¬ 
cionan información sobre los parámetros del sistema de 
bases de datos que pueden ajustarse y sobre el modo en 
que deben escogerse los valores de esos parámetros. 
Los sistemas de bases de datos bien diseñados llevan a 
cabo automáticamente todos los ajustes posibles, lo que 
libera al usuario o al administrador de la base de datos 
de esa carga. Por ejemplo, en muchos sistemas de bases 
de datos el tamaño de la memoria intermedia es fijo pero 
ajustable. Si el sistema ajusta de manera automática el 
tamaño de la memoria intermedia observando los indi¬ 
cadores como las tasas de fallo de las páginas, el usua¬ 
rio no tendrá que preocuparse por el ajuste del tamaño 
de la memoria intermedia. 


El tercer nivel es el nivel superior. Incluye el esque¬ 
ma y las transacciones. El administrador puede ajustar 
el diseño del esquema, los índices que se crean y las 
transacciones que se ejecutan para mejorar el rendi¬ 
miento. El ajuste en este nivel es, comparativamente, 
independiente del sistema. 

Los tres niveles de ajuste interactüan entre sí; hay 
que considerarlos en conjunto al ajustar los sistemas. 
Por ejemplo, el ajuste en un nivel superior puede hacer 
que el cuello de botella pase del sistema de discos a la 
CPU o viceversa. 

21.2.3. Ajuste del hardware 

Incluso en un sistema de procesamiento de transaccio¬ 
nes bien diseñado, cada transacción suele tener que rea¬ 
lizar al menos unas cuantas operaciones de E/S, si los 
datos necesarios para la transacción se hallan en el dis¬ 
co. Un factor importante en el ajuste de un sistema de 
procesamiento de transacciones, es asegurarse de que 
el subsistema de disco puede admitir la velocidad en 
que se solicitan las operaciones de E/S. Por ejemplo, 
los discos de hoy en día tienen un tiempo de acceso de 
unos diez milisegundos y velocidades de transferencia 
de veinte megabytes por segundo, lo que da cerca de 
cien operaciones de E/S de acceso aleatorio de un 
kilobyte cada una. Si cada transacción necesita exacta¬ 
mente dos operaciones de E/S, cada disco soportará 
como mucho cincuenta transacciones por segundo. La 
única manera de soportar más transacciones por segun¬ 
do es aumentar el número de discos. Si el sistema tie¬ 
ne que soportar n transacciones por segundo y cada una 
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de ella lleva a cabo dos operaciones de E/S, hay que 
dividir (o fragmentar de otra manera) los datos entre 
ni 50 discos (ignorando el sesgo). 

Hay que tener en cuenta que el factor limitador no 
es la capacidad del disco, sino la velocidad en que se 
puede tener acceso a los datos aleatorios (limitada, a 
su vez, por la velocidad a la que se puede desplazar 
el brazo del disco). El número de operaciones de E/S 
por transacción puede reducirse almacenando más 
datos en la memoria. Si todos los datos se hallan en 
la memoria no habrá operaciones de E/S en el disco 
salvo por las operaciones de escritura. Guardar los 
datos utilizados con frecuencia en la memoria redu¬ 
ce el número de operaciones de E/S y compensa el 
coste extra de la memoria. Guardar los datos utiliza¬ 
dos con muy poca frecuencia en la memoria sería un 
despilfarro, dado que la memoria es mucho más cara 
que los discos. 

El problema es, para una cantidad dada de dinero 
disponible para gastarlo en discos o en memoria, hallar 
la mejor manera de gastar el dinero para obtener el 
número máximo de transacciones por segundo. Una 
reducción de una operación de E/S por segundo ahorra 
(precio por unidad de disco) / (accesos por segundo por 
disco). Por tanto, si se tiene acceso a una página con¬ 
creta n veces por segundo, el ahorro debido a guardar¬ 
la en la memoria es n veces el valor calculado anterior¬ 
mente. Guardar una página en la memoria cuesta (precio 
por MB de memoria) / (páginas por MB de memoria). 
Por tanto, el punto de equilibrio es 

precio por unidad de disco precio por MB de memoria 

accesos por segundo por disco páginas por MB de memoria 

Se puede reordenar la ecuación y sustituir los valo¬ 
res actuales por cada uno de los parámetros citados más 
arriba para obtener un valor de n\ si se tiene acceso a 
una página con una frecuencia mayor que ésta merece 
la pena comprar suficiente memoria como para alma¬ 
cenarla. La tecnología de discos y los precios actuales 
de los discos dan un valor de n de alrededor de 1/300 
de veces por segundo (o, de manera equivalente, una 
vez cada cinco minutos) para las páginas a las que se 
tiene acceso de manera aleatoria. 

Este razonamiento se refleja en la recomendación 
denominada regla de los cinco minutos: si una página 
se usa más de una vez cada cinco minutos se debe guar¬ 
dar en la caché de memoria. En otras palabras, merece 
la pena comprar suficiente memoria para guardar en la 
caché todas las páginas a las que se tiene acceso al menos 
una vez cada cinco minutos de promedio. Para los datos 
a los que se tiene acceso con menos frecuencia hay que 
comprar discos suficientes para soportar la tasa de E/S 
exigida por los datos. 

La fórmula para hallar el punto de equilibrio depen¬ 
de de factores, como los costes de los discos y de la 
memoria, que han cambiado en factores de cien o de 
mil en la última década. No obstante, resulta interesan¬ 


te observar que los índices de los cambios han sido tales 
que el punto de equilibrio ha permanecido en unos cin¬ 
co minutos; ¡la regla de los cinco minutos no se ha vuel¬ 
to la regla de la hora o la regla del segundo! 

Para los datos con acceso secuencial se puede leer 
un número de páginas por segundo significativamente 
mayor. Suponiendo que se lee cada vez un megabyte de 
datos, se obtiene la regla del minuto, que indica que 
los datos con acceso secuencial deben guardarse en la 
caché de memoria si se utilizan al menos una vez por 
minuto. 

Las recomendaciones sólo tienen en cuenta el núme¬ 
ro de operaciones de E/S y no tienen en consideración 
factores como el tiempo de respuesta. Algunas aplica¬ 
ciones necesitan guardar en la memoria incluso los datos 
que se utilizan con poca frecuencia para soportar tiem¬ 
pos de respuesta inferiores o similares al tiempo de acce¬ 
so al disco. 

Otro aspecto del ajuste es si se debe utilizar RAID 1 
o RAID 5. La respuesta depende de la frecuencia con 
que se actualicen los datos, dado que RAID 5 es mucho 
más lento que RAID 1 en las operaciones aleatorias de 
escritura: RAID 5 necesita dos operaciones de lectura 
y dos operaciones de escritura para ejecutar una sola 
solicitud aleatoria de escritura. Si una aplicación reali¬ 
za / operaciones aleatorias de lectura y e operaciones 
aleatorias de escritura por segundo para soportar un 
intercambio concreto, una implementación de RAID 5 
necesitaría / + \e operaciones de E/S por segundo, mien¬ 
tras que una implementación de RAID 1 necesitaría / + 
e operaciones de E/S por segundo. Se puede calcular el 
número de discos necesario para soportar las operacio¬ 
nes de E/S necesarias por segundo dividiendo el resul¬ 
tado del cálculo por cien operaciones de E/S por segun¬ 
do (para los discos de la generación actual). Para muchas 
aplicaciones, / y e son lo bastante grandes como para 
que (/ + c)/100 discos puedan guardar con facilidad dos 
copias de todos los datos. Para esas aplicaciones, si se 
utiliza RAID 1, ¡el número necesario de discos es real¬ 
mente menor que el número necesario de discos si se 
emplea RAID 5! Por tanto, RAID 5 sólo resulta útil 
cuando los requisitos de almacenamiento de datos son 
muy grandes, pero las velocidades de E/S y los requi¬ 
sitos de transferencia de datos son pequeños, es decir, 
para datos muy grandes y muy «fríos». 

21.2.4. Ajuste del esquema 

Dentro de las restricciones de la forma normal escogida 
es posible dividir las relaciones verticalmente. Por ejem¬ 
plo, considérese la relación cuenta, con el esquema 

cuenta ( número-cuenta, nombre-sucursal, saldo) 

para la que número-cuenta es una clave. Dentro de las 
restricciones de las formas normales (formas normales 
BCNF y tercera) se puede dividir la relación cuenta en 
dos relaciones: 
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sucursal-cuenta ( número-cuenta, nombre-sucursal) 
saldo-cuenta ( número-cuenta, saldo) 

Las dos representaciones son lógicamente equivalen¬ 
tes, dado que número-cuenta es una clave, pero tienen 
características de rendimiento diferentes. 

Si la mayor parte de los accesos a la información de 
la cuenta sólo examinan número-cuenta y saldo, pue¬ 
den ejecutarse sobre la relación saldo-cuenta, y es pro¬ 
bable que el acceso resulte algo más rápido, dado que 
no se captura el atributo nombre-sucursal. Por el mis¬ 
mo motivo, cabrán en la memoria intermedia más tupias 
de saldo-cuenta que las correspondientes tupias de cuen¬ 
ta, lo que vuelve a generar un mayor rendimiento. Este 
efecto sería especialmente destacado si el atributo nom¬ 
bre-sucursal fuera de gran tamaño. Por tanto, un esque¬ 
ma que consistiera en sucursal-cuenta y cuenta-saldo 
sería preferible en este caso a otro que consistiera en la 
relación cuenta. 

Por otro lado, si la mayor parte de los accesos a la 
información de la cuenta necesitan tanto saldo como 
nombre-sucursal, el empleo de la relación cuenta será 
preferible, dado que se evitará el coste de la fusión de 
saldo-cuenta y sucursal-cuenta. Además, la sobrecar¬ 
ga de almacenamiento sería menor, dado que sólo ha¬ 
bría una relación y no se replicaría el atributo número- 
cuenta. 

Otro truco para mejorar el rendimiento es guardar 
una relación desnormalizada, como puede ser una 
fusión de cuenta y de impositor, donde la información 
sobre los nombres de las sucursales y sobre los saldos 
se repitiera para cada titular de una cuenta. Hay que rea¬ 
lizar más esfuerzo para asegurarse de que la relación es 
consistente siempre que se realice una actualización. 
No obstante, una consulta que capture los nombres de 
los clientes y sus saldos asociados se aceleraría, dado 
que la fusión de cuenta con impositor se habría calcu¬ 
lado previamente. Si se ejecuta con frecuencia una con¬ 
sulta de este tipo, y hay que llevarla a cabo con la máxi¬ 
ma eficiencia posible, la relación desnormalizada puede 
resultar beneficiosa. 

Las vistas materializadas pueden proporcionar las 
ventajas que ofrecen las relaciones desnormalizadas, 
al coste de algún almacenamiento extra; el ajuste del 
rendimiento de las vistas materializadas se describe 
en el Apartado 21.2.6. Una de las principales venta¬ 
jas de las vistas materializadas respecto de las rela¬ 
ciones desnormalizadas es que el mantenimiento de 
la consistencia de los datos redundantes pasa a ser 
labor del sistema de bases de datos, no del programa¬ 
dor. Por tanto, las vistas materializadas resultan pre¬ 
feribles, siempre que las soporte el sistema de bases 
de datos. 

Otro enfoque de la aceleración del cálculo de la 
fusión sin materializarla es agrupar los registros que 
coincidirán en la fusión en la misma página del disco. 
Estas organizaciones agrupadas de archivos se vieron 
en el Apartado 11.7.2. 


21.2.5. Ajuste de los índices 

Se pueden ajustar los índices de un sistema para mejo¬ 
rar el rendimiento. Si las consultas constituyen el cue¬ 
llo de botella se las suele poder acelerar creando los 
índices adecuados en las relaciones. Si lo constituyen 
las actualizaciones, puede que haya demasiados índi¬ 
ces, que hay que actualizar cuando se actualizan las rela¬ 
ciones. La eliminación de índices puede que acelere 
algunas actualizaciones. La elección del tipo de índice 
también es importante. Algunos sistemas de bases de 
datos soportan diferentes tipos de índices, como los índi¬ 
ces asociativos y los índices de árboles B. Si las con¬ 
sultas más frecuentes son de rango, es preferible utili¬ 
zar índices de árboles B a los índices asociativos. Otro 
parámetro ajustable es la posibilidad de hacer que un 
índice tenga agrupación. Sólo se puede hacer un índice 
con agrupación por relación, guardando la relación orde¬ 
nada por los atributos del índice. Generalmente con¬ 
viene hacer el índice con agrupación que beneficie al 
mayor número de consultas y de actualizaciones. 

Para ayudar a identificar los índices que se deben 
crear y el índice (si es que hay alguno) de cada relación 
que se debe agrupar, algunos sistemas de bases de datos 
proporcionan asistentes para el ajuste. Estas herra¬ 
mientas utilizan el historial de consultas y de actuali¬ 
zaciones (denominado carga de trabajo) para estimar 
los efectos de varios índices en el tiempo de ejecución 
de las consultas y de las actualizaciones en la carga de 
trabajo. Las recomendaciones sobre los índices que se 
deben crear se basan en estas estimaciones. 

21.2.6. Uso de las vistas materializadas 

El uso de las vistas materializadas puede acelerar enor¬ 
memente ciertos tipos de consultas, en especial las con¬ 
sultas de agregación. Recuérdese el ejemplo del Apar¬ 
tado 14.5 en que el importe total de los créditos de cada 
sucursal (obtenido sumando los importes de los crédi¬ 
tos de todos los créditos de la sucursal) se solicita con 
frecuencia. Como se vio en ese apartado, la creación de 
una vista materializada que guarde el importe total de 
los créditos de cada sucursal puede acelerar enorme¬ 
mente estas consultas. 

Las vistas materializadas deben emplearse con cui¬ 
dado, no obstante, dado que no sólo supone una sobre¬ 
carga de espacio almacenarlas sino que, lo que es más 
importante, su mantenimiento también supone una 
sobrecarga de tiempo. En el caso del mantenimiento 
inmediato de las vistas, si las actualizaciones de una 
transacción afectan a la vista materializada, hay que 
actualizarla como parte de la misma transacción. Por 
tanto, puede que la transacción se ejecute más lenta¬ 
mente. En el caso del mantenimiento diferido de las 
vistas, la vista materializada se actualiza posteriormente; 
hasta que se actualice puede que la vista materializada 
sea inconsistente con las relaciones de la base de datos. 
Por ejemplo, puede que la vista materializada se actua- 
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lice cuando la utilice una consulta o que se actualice de 
manera periódica. El empleo del mantenimiento diferi¬ 
do reduce la carga de las transacciones de actualización. 

Un problema importante es el modo en que se selec¬ 
cionan las vistas materializadas que hay que mantener. 
El administrador del sistema puede realizar la selección 
de modo manual examinando los tipos de consultas de 
la carga de trabajo y averiguando las consultas que nece¬ 
sitan ejecutarse más rápidamente y las actualizaciones 
o consultas que pueden ejecutarse más lentamente. 
A partir del examen, el administrador del sistema pue¬ 
de escoger un conjunto adecuado de vistas materializa¬ 
das. Por ejemplo, puede que el administrador descubra 
que se utiliza con frecuencia un agregado determinado 
y decida materializarlo, o puede que halle que una fusión 
concreta se calcula con frecuencia y decida materiali¬ 
zarla. 

Sin embargo, la selección manual resulta tediosa 
incluso para conjuntos de tipos de consultas modera¬ 
damente grandes y puede que resulte difícil realizar una 
buena selección, dado que exige comprender los costes 
de diferentes alternativas; sólo el optimizador de con¬ 
sultas puede estimar los costes con una precisión razo¬ 
nable, sin ejecutar realmente la consulta. Por tanto, pue¬ 
de que sólo se halle un buen conjunto de vistas mediante 
el procedimiento de pmeba y error, es decir, materiali¬ 
zando una o varias vistas, ejecutando la carga de traba¬ 
jo y midiendo el tiempo empleado para ejecutar las con¬ 
sultas de la carga de trabajo. El administrador repetirá 
el proceso hasta que se halle un conjunto de vistas que 
dé un rendimiento aceptable. 

Una opción mejor es proporcionar soporte para la 
selección de las vistas materializadas desde el interior 
del propio sistema de bases de datos, integrado con el 
optimizador de consultas. Algunos sistemas de bases de 
datos, como Microsoft SQL Server 7.5 y RedBrick Data 
Warehouse de Informix, ofrecen herramientas para ayu¬ 
dar al administrador de la base de datos en la selección 
de los índices y de las vistas materializadas. Estas herra¬ 
mientas examinan la carga de trabajo (el historial de con¬ 
sultas y de actualizaciones) y sugiere los índices y las 
vistas que hay que materializar. El usuario tiene la posi¬ 
bilidad de especificar la importancia de la aceleración de 
las diferentes consultas, lo que el administrador tiene en 
cuenta al seleccionar las vistas que vaya a materializar. 

La herramienta de selección de vistas materializadas 
de Microsoft también permite que el usuario formule 
preguntas del tipo «¿qué pasaría si...?», por lo que el 
usuario puede escoger una vista y el optimizador esti¬ 
mará el efecto de materializarla en el coste total de la 
carga de trabajo y en los costes individuales de los dife¬ 
rentes tipos de consultas o de actualizaciones en la car¬ 
ga de trabajo. 

De hecho, incluso las técnicas de selección automa¬ 
tizadas se implementan de manera parecida interna¬ 
mente: las diferentes opciones se pmeban y para cada 
una el optimizador de consultas estima los costes y las 
ventajas de materializarla. 


La heurística impaciente de la selección de vistas 
materializadas opera aproximadamente de este modo: 
se estiman las ventajas de la materialización de las dife¬ 
rentes vistas y se escoge la vista que ofrece la máxima 
ventaja o la máxima ventaja por unidad de espacio (es 
decir, la ventaja dividida por el espacio necesario para 
guardar la vista). Una vez la heurística ha seleccionado 
una vista puede que hayan cambiado las ventajas de otras 
vistas, por lo que la heurística vuelve a calcularlas y esco¬ 
ge la segunda mejor vista para su materialización. El pro¬ 
ceso continúa hasta que se agota el espacio de disco dis¬ 
ponible para guardar las vistas materializadas o bien el 
coste del mantenimiento de las vistas supera los límites 
aceptables. 

21.2.7. Ajuste de las transacciones 

En este apartado se estudian dos enfoques de la mejo¬ 
ra del rendimiento de las transacciones: 

• Mejora de la orientación del conjunto 

• Reducción de la contención de los bloqueos 

En el pasado los optimizadores de muchos sistemas 
de bases de datos no eran especialmente buenos, por lo 
que el modo en que se había escrito la consulta tenía 
gran influencia en el modo en que se ejecutaba y, por 
tanto, en el rendimiento. Los optimizadores avanzados 
de hoy en día pueden transformar incluso las consultas 
mal escritas y ejecutarlas de manera eficiente, por lo 
que la necesidad de ajustar las consultas una a una es 
menos importante que en el pasado. No obstante, las 
consultas complejas que contienen subconsultas anida¬ 
das no las suelen optimizar muy bien. La mayor parte 
de los sistemas proporcionan un mecanismo para ave¬ 
riguar el plan de ejecución preciso de las consultas; esta 
información puede utilizarse para volver a escribir la 
consulta de forma que el optimizador pueda trabajar 
mejor con ella. 

En SQL incorporado, si se ejecuta con frecuencia 
una consulta con valores diferentes de un parámetro 
puede que resulte de ayuda combinar las llamadas en 
una consulta más orientada al conjunto que sólo se eje¬ 
cute una vez. Los costes de comunicación de las con¬ 
sultas SQL pueden resultar elevados en los sistemas 
cliente-servidor, por lo que la combinación de las lla¬ 
madas de SQL incorporado resulta de especial ayuda 
en esos sistemas 

Por ejemplo, considérese un programa que pase por 
cada departamento especificado en una lista invocando 
una consulta de SQL para buscar los gastos totales del 
departamento empleando la estructura group by en la 
relación gastosifecha, empleado, departamento, impor¬ 
te). Si la relación gastos no tiene un índice con agrupa¬ 
ción en departamento, cada consulta de ese tipo dará 
lugar a una exploración de la relación. En lugar de eso, 
se puede utilizar una sola consulta SQL para averiguar 
los gastos totales de todos los departamentos; la con- 
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sulta puede evaluarse con una sola exploración. Los 
departamentos importantes pueden examinarse luego 
en esta relación temporal (mucho más pequeña) que 
contiene el agregado. Aunque hay un índice que per¬ 
mita el acceso eficiente a las tupias de un departamen¬ 
to dado, el empleo de varias consultas SQL puede supo¬ 
ner una gran sobrecarga de comunicaciones en los 
sistemas cliente-servidor. El coste de comunicaciones 
puede reducirse empleando una sola consulta SQL, cap¬ 
turando los resultados para el lado cliente y pasando por 
los resultados para hallar las tupias necesarias. 

Otra técnica muy utilizada en los sistemas cliente- 
servidor para reducir el coste de las comunicaciones y 
la compilación de SQL es utilizar procedimientos alma¬ 
cenados, en los que las consultas se guardan en el ser¬ 
vidor en forma de procedimientos almacenados, que 
pueden estar compilados con antelación. Los clientes 
pueden invocar estos procedimientos almacenados en 
lugar de comunicar consultas enteras. 

La ejecución concurrente de diferentes tipos de tran¬ 
sacciones puede llevar a veces a un rendimiento bajo 
por la contención de los bloqueos. Considérese, por 
ejemplo, una base de datos bancaria. De día se ejecu¬ 
tan de manera casi continua numerosas transacciones 
de actualización de pequeño tamaño. Supóngase que se 
ejecuta al mismo tiempo una consulta de gran tamaño 
que calcula estadísticas de las sucursales. Si la consul¬ 
ta ejecuta una exploración de la relación puede que blo¬ 
quee todas las actualizaciones de la relación mientras 
se ejecuta, y eso puede tener un efecto desastroso en el 
rendimiento del sistema. 

Algunos sistemas de bases de datos (Oracle, por 
ejemplo) permiten el control de la concurrencia multi- 
versión, por lo que las consultas se ejecutan sobre una 
instantánea de los datos, y las actualizaciones pueden 
seguir de manera concurrente. Esta característica debe 
utilizarse si está disponible. Si no se encuentra dispo¬ 
nible, una opción alternativa es ejecutar las consultas 
de gran tamaño en momentos en que las actualizacio¬ 
nes sean pocas o no haya ninguna. Para las bases de 
datos que soporten los sitios Web puede que no exista 
ese periodo de calma para las actualizaciones. 

Otra opción es utilizar niveles de consistencia más 
débiles, por lo que la evaluación de la consulta tendrá 
un impacto mínimo en las actualizaciones concurren¬ 
tes, pero no se garantiza que los resultados de la con¬ 
sulta sean consistentes. La semántica de la aplicación 
determina si son aceptables las respuestas aproximadas 
(inconsistentes). 

Las transacciones de actualización de larga duración 
pueden crear problemas de rendimiento con los regis¬ 
tros del sistema e incrementar el tiempo que éste tarda 
en recuperarse de las caídas. Si una transacción lleva a 
cabo muchas actualizaciones puede que el registro del 
sistema se llene antes incluso de que se complete la tran¬ 
sacción, en cuyo caso habrá que retroceder la transac¬ 
ción. Si una transacción de actualización se ejecuta duran¬ 
te mucho tiempo (aunque tenga pocas actualizaciones) 


puede que bloquee la eliminación de las partes más anti¬ 
guas del registro, si el sistema de registros no está bien 
diseñado. Nuevamente, este bloqueo puede llevar a que 
se llene el registro histórico. 

Para evitar estos problemas muchos sistemas de bases 
de datos imponen límites estrictos para el número de 
actualizaciones que puede llevar a cabo una sola tran¬ 
sacción. Aunque el sistema no imponga estos límites 
suele resultar de ayuda fraccionar las transacciones de 
actualización de gran tamaño en conjuntos de transac¬ 
ciones de actualización de menor tamaño siempre que 
sea posible. Por ejemplo, una transacción que dé un 
aumento a cada empleado de una gran empresa puede 
dividirse en una serie transacciones de pequeño tama¬ 
ño, cada una de las cuales se asigna a un pequeño ran¬ 
go de identidades de empleados. Estas transacciones se 
denominan transacciones procesadas por minilotes. 
No obstante, las transacciones procesadas por minilo¬ 
tes deben emplearse con cuidado. En primer lugar, si 
hay actualizaciones concurrentes en el conjunto de 
empleados puede que el resultado del conjunto de tran¬ 
sacciones de menor tamaño no sea equivalente al de la 
transacción única de gran tamaño. En segundo lugar, si 
se produce un fallo las transacciones confirmadas habrá 
aumentado el salario de algunos empleados pero no el 
de los demás. Para evitar este problema, en cuanto el 
sistema se recupere del fallo, hay que ejecutar las res¬ 
tantes transacciones del lote. 

21.2.8. Simulación del rendimiento 

Para comprobar el rendimiento de un sistema de bases 
de datos incluso antes de instalarlo se puede crear un 
modelo de simulación del rendimiento de ese sistema. 
En la simulación se modela cada servicio que aparece 
en la Figura 21.6, como la CPU, cada disco, la memo¬ 
ria intermedia y el control de concurrencia. En lugar de 
modelar los detalles de un servicio, puede que el mode¬ 
lo de simulación sólo capture algunos aspectos de cada 
uno, como el tiempo de servicio, es decir, el tiempo 
que tarda en acabar de procesar una solicitud una vez 
comenzado el procesamiento. Por tanto, la simulación 
puede modelar el acceso a disco partiendo sólo del tiem¬ 
po medio de acceso a disco. 

Dado que las solicitudes de un servicio suelen tener 
que aguardar su turno, cada servicio tiene asociada una 
cola en el modelo de simulación. Cada transacción con¬ 
siste en una serie de solicitudes. Las solicitudes se enco¬ 
lan según llegan y se atienden de acuerdo con la políti¬ 
ca de cada servicio, como puede ser que el primero en 
llegar sea el primero en ser atendido. Los modelos de 
los servicios como la CPU y los discos operan concep¬ 
tualmente en paralelo, para tener en cuenta el hecho de 
que estos subsistemas operan en paralelo en los siste¬ 
mas reales. 

Una vez creado el modelo de simulación para el pro¬ 
cesamiento de las transacciones, el administrador del 
sistema puede ejecutar en él varios experimentos. El 
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administrador puede utilizar los experimentos con tran¬ 
sacciones simuladas que lleguen con diferentes veloci¬ 
dades para averiguar el modo en que se comportaría el 
sistema bajo diferentes condiciones de carga. También 
puede ejecutar otros experimentos que varíen los tiem¬ 


pos de servicio de cada servicio para averiguar la sen¬ 
sibilidad del rendimiento a cada uno de ellos. También 
se pueden variar los parámetros del sistema de modo 
que se pueda realizar el ajuste del rendimiento en el 
modelo de simulación. 


21.3. PRUEBAS DE RENDIMIENTO 


A medida que se van estandarizando los servidores de 
bases de datos, el factor diferenciador entre los pro¬ 
ductos de los diferentes fabricantes es el rendimiento 
de esos productos. Las pruebas de rendimiento son 
conjuntos de tareas que se emplean para cuantificar el 
rendimiento de los sistemas de software. 

21.3.1. Familias de tareas 

Dado que la mayor parte de los sistemas de software, 
como las bases de datos, son complejos hay bastante 
variación en su implementación por los diferentes fabri¬ 
cantes. En consecuencia, hay una variación significati¬ 
va en su rendimiento en las diferentes tareas. Puede que 
un sistema sea el más eficiente en una tarea concreta y 
puede que otro lo sea en una tarea diferente. Por tanto, 
una sola tarea no suele resultar suficiente para cuantifi¬ 
car el rendimiento del sistema. En lugar de eso, el ren¬ 
dimiento de un sistema se mide mediante familias de 
tareas estandarizadas, denominadas pruebas de rendi¬ 
miento. 

La combinación de los resultados de rendimiento de 
varias tareas debe realizarse con cuidado. Supóngase 
que se tienen dos tareas, T { y T 2 , y que se mide el flujo 
de un sistema como el número de transacciones de cada 
tipo que se ejecutan en un tiempo dado (digamos, un 
segundo). Supóngase que el sistema A ejecuta T l a 99 
transacciones por segundo y que T 2 se ejecuta a una tran¬ 
sacción por segundo. De manera parecida, supóngase 
que el sistema B ejecuta T l yT 2 & 50 transacciones por 
segundo. Supóngase también que una carga de trabajo 
tiene una mezcla a partes iguales de los dos tipos de 
transacciones. 

Si se toma el promedio de los dos pares de resulta¬ 
dos (es decir, 99 y 1 frente a 50 y 50), pudiera parecer 
que los dos sistemas tienen el mismo rendimiento. Sin 
embargo, sería erróneo tomar los promedios de esta 
manera (si se ejecutaran 50 transacciones de cada tipo 
el sistema A tardaría unos 50,5 segundos en concluir¬ 
las, mientras que el sistema B las terminaría ¡en sólo 2 
segundos!). 

Este ejemplo muestra que una sola medida del ren¬ 
dimiento induce a error si hay más de un tipo de tran¬ 
sacción. El modo correcto de promediar los números es 
tomar el tiempo para concluir la carga de trabajo, en 
vez del flujo promedio de cada tipo de transacción. Se 
puede así calcular el rendimiento del sistema en tran¬ 


sacciones por segundo para una carga de trabajo con¬ 
creta con exactitud. Por tanto, el sistema A tarda 50,5/100, 
que son 0,505 segundos por transacción, mientras que 
el sistema B tarda 0,02 segundos por transacción, en pro¬ 
medio. En términos de flujo el sistema A se ejecuta a un 
promedio de 1,98 transacciones por segundo, mientras 
que el sistema B se ejecuta a 50 transacciones por segun¬ 
do. Suponiendo que las transacciones de todos los tipos 
son igual de probables el modo correcto de promediar 
los flujos respecto de los diferentes tipos de transaccio¬ 
nes es tomar la media armónica de los flujos. La media 
armónica de n flujos f x ,...,/« se define como 

_ n _ 

1 1 1 
— + — + • • • + — 


Para este ejemplo la media armónica de los flujos en el 
sistema A es 1,98. Para el sistema B es 50. Por tanto, el 
sistema B es aproximadamente veinticinco veces más 
rápido que el sistema A para una carga de trabajo con¬ 
sistente en una mezcla a partes iguales de los dos tipos 
de transacciones de ejemplo. 

21.3.2. Clases de aplicaciones de bases 
de datos 

El procesamiento en conexión de transacciones (Onli¬ 
ne Transaction Processing, OLTP) y la ayuda a la 
toma de decisiones (incluyendo el procesamiento en 
conexión analítico [Online Analytical Processing, 
OLAP]) son dos grandes clases de aplicaciones mane¬ 
jadas por los sistemas de bases de datos. Estas dos cla¬ 
ses de tareas tienen necesidades diferentes. La elevada 
concurrencia y las técnicas inteligentes para acelerar el 
procesamiento de las operaciones de compromiso se nece¬ 
sitan para soportar una elevada tasa de transacciones de 
actualización. Por otro lado, los buenos algoritmos para 
la evaluación de consultas y la optimización de las con¬ 
sultas son necesarios para la ayuda a la toma de decisio¬ 
nes. La arquitectura de algunos sistemas de bases de datos 
se ha ajustado para el procesamiento de las transaccio¬ 
nes; la de otros, como la serie DBC de Teradata de siste¬ 
mas paralelos de bases de datos, para el ayuda a la toma 
de decisiones. Otros fabricantes intentan conseguir un 
equilibrio entre las dos tareas. 
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Las aplicaciones suelen tener una mezcla de necesi¬ 
dades de procesamiento de transacciones y ayuda a la 
toma de decisiones. Por tanto, el mejor sistema de bases 
de datos para cada aplicación depende de la mezcla de 
las dos necesidades que tenga la aplicación. 

Supóngase que se tienen resultados de flujo para las 
dos clases de aplicaciones por separado y la aplicación 
en cuestión tiene una mezcla de transacciones de las dos 
clases. Hay que ser precavido incluso al tomar la media 
armónica de los resultados de flujo, debido a la inter¬ 
ferencia entre las transacciones. Por ejemplo, una tran¬ 
sacción de ayuda a la toma de decisiones que tarde 
mucho en ejecutarse puede adquirir varios bloqueos, lo 
que puede evitar el progreso de las transacciones de 
actualización. La media armónica de los flujos sólo debe 
utilizarse si las transacciones no interfieren entre sí. 

21.3.3. Las pruebas TPC 

El Consejo para el rendimiento del procesamiento 
de las transacciones (Transaction Processing Per¬ 
formance Council, TPC) ha definido una serie de nor¬ 
mas de índices para los sistemas de bases de datos. Los 
índices TPC se definen con gran minuciosidad. Definen 
el conjunto de relaciones y el tamaño de las tupias. Defi¬ 
nen el número de tupias de las relaciones no como un 
número fijo, sino como un múltiplo del número de tran¬ 
sacciones por segundo que se afirma que se realizan, 
para reflejar que una tasa mayor de ejecución de tran¬ 
sacciones probablemente se halle correlacionada con 
un número mayor de cuentas. La métrica del rendimiento 
es el flujo, expresado como transacciones por segun¬ 
do (TPS). Cuando se mide el rendimiento, el sistema 
debe proporcionar un tiempo de respuesta que se halle 
dentro de ciertos límites, de modo que un flujo elevado 
no pueda obtenerse a expensas de tiempos de respues¬ 
ta muy elevados. Además, para las aplicaciones profe¬ 
sionales, el coste es de gran importancia. Por tanto, el 
índice TPC también mide el rendimiento en términos 
de precio por TPS. Puede que los sistemas de gran 
tamaño tengan un elevado número de transacciones por 
segundo, pero puede que resulten caros (es decir, que 
tengan un precio elevado por TPS). Además, una com¬ 
pañía no puede afirmar que tiene resultados de los índi¬ 
ces TPC en sus sistemas sin una auditoría externa que 
asegure que el sistema sigue fielmente la definición del 
índice, incluyendo el soporte pleno de las propiedades 
ACID de las transacciones. 

El primero de la serie fue el índice TPC-A, que se 
definió en 1989. Este índice simula una aplicación ban- 
caria típica mediante un solo tipo de transacción que 
modela la retirada y el depósito de efectivo en un caje¬ 
ro automático. La transacción actualiza varias relacio¬ 
nes (como el saldo del banco, el saldo del cajero y el 
saldo del cliente) y añade un registro a una relación de 
seguimiento para la auditoría. El índice también incor¬ 
pora la comunicación con los terminales para modelar 
el rendimiento de extremo a extremo del sistema de 


manera realista. El índice TPC-B se diseñó para pro¬ 
bar el rendimiento central del sistema de bases de datos, 
junto con el sistema operativo en el que se ejecuta el 
sistema. Elimina las partes del índice TPC-A que tratan 
de los usuarios, de las comunicaciones y de los termi¬ 
nales para centrarse en el servidor de bases de datos dor¬ 
sal. Ni TPC-A ni TPC-B se emplean mucho hoy en día. 

El índice TPC-C se diseñó para modelar un sistema 
más complejo que el del índice TPC-A. El índice TPC- 
C se concentra en las actividades principales de un entor¬ 
no de admisión de pedidos, como son la entrada y la 
entrega de pedidos, el registro de los pagos, la verifica¬ 
ción del estado de los pedidos y el seguimiento de los 
niveles de inventarios. El índice TPC-C se sigue utili¬ 
zando con profusión para el procesamiento de transac¬ 
ciones. 

El índice TPC-D se diseñó para probar el rendi¬ 
miento de los sistemas de bases de datos en consultas 
de ayuda a la toma de decisiones. Los sistemas de ayu¬ 
da a la toma de decisiones se están haciendo cada vez 
más importantes hoy en día. Los índices TPC-A, TPC- 
B y TPC-C miden el rendimiento de las cargas de pro¬ 
cesamiento de transacciones y no deben utilizarse como 
medida del rendimiento en consultas de ayuda a la toma 
de decisiones. La D de TPC-D viene de ayuda a la toma 
de Decisiones. El esquema del índice TPC-D modela 
una aplicación de ventas/distribución, con componen¬ 
tes, clientes y pedidos, junto con cierta información auxi¬ 
liar. El tamaño de las relaciones se define como una rela¬ 
ción y el tamaño de la base de datos es el tamaño total 
de todas las relaciones, expresado en gigabytes. TPC-D 
con un factor de escala de uno representa el índice TPC- 
D para una base de datos de un gigabyte, mientras que 
el factor de escala diez representa una base de datos de 
diez gigabytes. La carga de trabajo del índice consiste 
en un conjunto de diecisiete consultas SQL que mode¬ 
lan tareas que se ejecutan frecuentemente en los siste¬ 
mas de ayuda a la toma de decisiones. Parte de las con¬ 
sultas utilizan características complejas de SQL, como 
las consultas de agregación y las consultas anidadas. 

Los usuarios de los índices se dieron cuenta pronto 
de que las diferentes consultas TPC-D podían acelerar¬ 
se de manera significativa empleando las vistas mate¬ 
rializadas y otra información redundante. Hay aplica¬ 
ciones, como las tareas periódicas de información, donde 
las consultas se conocen con antelación y las vistas mate¬ 
rializadas pueden seleccionarse con cuidado para ace¬ 
lerar las consultas. Resulta necesario, no obstante, tener 
en cuenta la sobrecarga que supone mantener las vistas 
materializadas. 

El índice TPC-R (donde la R viene de informar 
(Reporting)) supone un refinamiento del índice TPC- 
D. El esquema es el mismo, pero hay veintidós consul¬ 
tas, de las cuales dieciséis provienen de TPC-D. Ade¬ 
más, hay dos actualizaciones, un conjunto de inserciones 
y un conjunto de eliminaciones. Se permite que la base 
de datos que ejecuta el índice utilice vistas materializa¬ 
das y otra información redundante. 
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A diferencia de esto, el índice TPC-H (donde la H 
representa ad hoc) utiliza el mismo esquema y la mis¬ 
ma carga de trabajo que TPC-R, pero prohíbe las vistas 
materializadas y otra información redundante y permi¬ 
te los índices sólo en las claves principales y ajenas. 
Este índice modela consultas ad hoc donde las consul¬ 
tas no se conocen con anterioridad, por lo que no es 
posible crear con antelación vistas materializadas ade¬ 
cuadas. 

Tanto TPC-H como TPC-R miden el rendimiento de 
esta manera: el test de potencia ejecuta las consultas y 
las actualizaciones una a una de manera secuencial y 
3.600 segundos divididos por la media geométrica de 
los tiempos de ejecución de las consultas (en segundos) 
da una medida de las consultas por hora. El test de flu¬ 
jo ejecuta varias corrientes en paralelo, cada una de las 
cuales ejecuta las veintidós consultas. También hay una 
corriente de actualizaciones paralela. Aquí el tiempo 
total de toda la ejecución se utiliza para calcular el núme¬ 
ro de consultas por hora. 

La métrica compuesta consultas por hora, que es 

la métrica global, se obtiene como la raíz cuadrada del 
producto de las métricas de potencia y de flujo. Se defi¬ 
ne una métrica compuesta precio/rendimiento divi¬ 
diendo el precio del sistema por la métrica compuesta. 

El índice de comercio Web TPC-W es un índice de 
extremo a extremo que modela los sitios Web que tie¬ 
nen contenido estático (imágenes, sobre todo) y conte¬ 
nido dinámico generado a partir de una base de datos. 
Se permite de manera explícita el almacenamiento en 
caché del contenido dinámico, dado que resulta muy 
útil para acelerar los sitios Web. El índice modela una 


librería electrónica, y como otros índices TPC, propor¬ 
ciona diferentes factores de escala. La métrica de ren¬ 
dimiento principal son las interacciones Web por 
segundo (Web interactions per second, WIPS) y el 
precio por WIPS. 

21.3.4. Las pruebas BDOO 

La naturaleza de las aplicaciones de las bases de datos 
orientadas a objetos (BDOO) es diferente de las de las 
aplicaciones típicas de procesamiento de transacciones. 
Por tanto, se ha propuesto un conjunto diferente de índi¬ 
ces para las BDOO. La prueba operaciones con obje¬ 
tos, versión 1, popularmente conocido como índice 
OOl, fue una de las primeras propuestas. El índice 007 
sigue una filosofía diferente de la de los índices TPC. 
Los índices TPC proporcionan uno o dos resultados (en 
términos del promedio de transacciones por segundo y 
de transacciones por segundo y por dólar); el índice 007 
proporciona un conjunto de resultados, que contienen 
un resultado de índice independiente para cada una de 
las diferentes clases de operaciones. El motivo de este 
enfoque es que no está todavía claro lo que es la tran¬ 
sacción BDOO típica. Está claro que esa transacción 
llevará a cabo ciertas operaciones, como recorrer un 
conjunto de objetos conectados o recuperar todos los 
objetos de una clase, pero no está claro exactamente la 
mezcla de tales operaciones que se utilizará. Por tanto, 
el índice proporciona resultados separados para cada 
clase de operaciones; los resultados pueden combinar¬ 
se de la manera adecuada, en función de la aplicación 
concreta. 


21.4. NORMALIZACIÓN 


Las normas definen las interfaces de los sistemas de 
software; por ejemplo, las normas definen la sintaxis y 
la semántica de los lenguajes de programación o las fun¬ 
ciones en la interfaz de los programas de aplicaciones 
o, incluso, los modelos de datos (como las normas de 
las bases de datos orientadas a los objetos). Hoy en día 
los sistemas de bases de datos son complejos y suelen 
estar constituidos por varias partes creadas de manera 
independiente que deben interactuar entre sí. Por ejem¬ 
plo, puede que los programas clientes se creen de mane¬ 
ra independiente de los sistemas dorsales, pero todos 
ellos deben poder interactuar entre sí. Puede que una 
empresa que tenga varios sistemas de bases de datos 
heterogéneos necesite intercambiar datos entre las bases 
de datos. En una situación de este tipo las normas desem¬ 
peñan un papel importante. 

Las normas formales son las que han sido desarro¬ 
lladas por una organización de normalización o por gru¬ 
pos de empresas mediante un procedimiento público. 
Los productos dominantes se convierten a veces en una 


norma de facto, en el sentido de que resultan acepta¬ 
dos de manera general como normas sin necesidad de 
ningún procedimiento formal de reconocimiento. Algu¬ 
nas normas formales, como muchos aspectos de las nor¬ 
mas SQL-92 y SQL: 1999, son normas anticipativas 
que lideran el mercado; definen las características que 
los fabricantes implementan posteriormente en los pro¬ 
ductos. En otros casos, las normas, o partes de las nor¬ 
mas, son normas reaccionarias, en el sentido de que 
intentan normalizar las características que ya han imple - 
mentado algunos fabricantes, y que pueden haberse con¬ 
vertido, incluso, en normas de facto. SQL-89 era, en 
muchos sentidos, reaccionario, dado que estandarizaba 
características, como la comprobación de la integridad, 
que ya estaban presentes en la norma SAA SQL de IBM 
y en otras bases de datos. 

Los comités para las normas formales suelen estar 
compuestos por representantes de los fabricantes y por 
miembros de grupos de usuarios y de organizaciones de 
normalización como la Organización internacional de 
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normalización (International Organization for Standar¬ 
dizaron, ISO) o el Instituto nacional americano de nor¬ 
malización (American National Standards Institute, 
ANSI) o de organismos profesionales como el Institu¬ 
to de ingenieros eléctricos y electrónicos (Institute of 
Electrical and Electronics Engineers, IEEE). Los comi¬ 
tés para las normas formales se reúnen de manera perió¬ 
dica y sus componentes presentan propuestas de carac¬ 
terísticas de la norma que hay que añadir o modificar. 
Tras un periodo de discusión (generalmente amplio), de 
modificaciones de la propuesta y de examen público, 
los integrantes de los comités votan la aceptación o el 
rechazo de las características. Cierto tiempo después de 
la definición e implementación de una norma quedan 
claras sus carencias y aparecen nuevas necesidades. El 
proceso de actualización de la norma comienza enton¬ 
ces y tras unos cuantos años suele publicarse una nue¬ 
va versión de la misma. Este ciclo suele repetirse cada 
pocos años hasta que finalmente (quizás muchos años 
más tarde) la norma se vuelve tecnológicamente irrele¬ 
vante o pierde su base de usuarios. 

La norma CODASYL de DBTG para bases de datos 
en red, formulada por el Grupo de trabajo para bases de 
datos (Database Task Group, DBTG), fue una de las pri¬ 
meras normas formales en este campo. Los productos de 
bases de datos de IBM solían establecer las normas de 
facto, dado que IBM ocupaba gran parte de este merca¬ 
do. Con el crecimiento de las bases de datos relacióna¬ 
les aparecieron nuevos competidores en el negocio de 
las bases de datos; por tanto, surgió la necesidad de nor¬ 
mas formales. En los últimos años Microsoft ha creado 
varias especificaciones que también se han convertido 
en normas de facto. Un ejemplo destacable es ODBC, 
que se utiliza actualmente en entornos que no son de 
Microsoft. JDBC, cuya especificación fue creada por Sun 
Microsystems, es otra norma de facto muy utilizada. 

Este apartado ofrece una introducción de muy alto 
nivel a las diferentes normas, concentrándose en los 
objetivos de cada norma. Las notas bibliográficas al final 
del capítulo ofrecen referencias de las descripciones 
detalladas de las normas mencionados en este apartado. 

21.4.1. Normas de SQL 

Dado que SQL es el lenguaje de consultas más utiliza¬ 
do se ha trabajado mucho en su normalización. ANSI e 
ISO, con los diferentes fabricantes de bases de datos, 
han desempeñado un papel protagonista en esta labor. 
La norma SQL-86 fue la versión inicial. La norma 
Arquitectura de aplicaciones de sistemas (Systems 
Application Architecture, SAA) de IBM para SQL se 
publicó en 1987. A medida que la gente identificaba la 
necesidad de más características se desarrollaron ver¬ 
siones actualizadas de la norma formal de SQL, deno¬ 
minadas SQL-89 y SQL-92. 

La última versión de la norma SQL, denominada 
SQL: 1999, añade varias características al lenguaje. Ya 
se han visto muchas de estas características en los capí¬ 


tulos anteriores, y se verán unas cuantas más en los 
siguientes. La norma se ha dividido en varias partes: 

• SQL/Lramework (Parte 1) proporciona una intro¬ 
ducción la norma. 

• SQL/Loundation (Parte 2) define los fundamentos 
de la norma: tipos, esquemas, tablas, vistas, con¬ 
sultas y sentencias de actualización, expresiones, 
modelo de seguridad, predicados, reglas de asig¬ 
nación, gestión de transacciones, etcétera. 

• SQL/CLI (Cali Level hrterface) (Parte 3) define las 
interfaces de los programas de aplicaciones con SQL. 

• SQL/PSM (Persistent Stored Modules) (Parte 4) 
define las extensiones de SQL para hacerlo proce- 
dimental. 

• SQL/Bindings (Parte 5) define las normas para 
SQL incorporado para diferentes lenguajes. 

Las características OLAP de SQL: 1999 (Apartado 
22.2.3) se han especificado como enmienda a la versión 
anterior de la norma SQL: 1999. Hay otras partes en 
desarrollo, incluyendo 

• Parte 7: SQL/Temporal aborda las normas para los 
datos temporales. 

• Parte 9: SQL/MED (Management of Extemal Data) 
define las normas para la realización de interfaces 
en los sistemas SQL con orígenes externos. Al 
escribir envolturas, los diseñadores de los sistemas 
pueden tratar los orígenes externos de datos, como 
pueden ser los archivos o los datos de bases de datos 
no relaciónales, como si fueran tablas externas. 

• Parte 10: SQL/OLB (Object Language Bindings) 
define las normas para la incrustación de SQL en 
Java. 

Los números que faltan (partes 6 y 8) tratan caracte¬ 
rísticas como el procesamiento de transacciones distri¬ 
buidas y los datos multimedia para las que todavía no hay 
ningún acuerdo sobre las normas. Las normas multime¬ 
dia pretenden tratar el almacenamiento y la recuperación 
de datos de texto, datos espaciales e imágenes fijas. 

21.4.2. Las normas de conectividad 
de las bases de datos 

La norma ODBC es una norma muy utilizada para la 
comunicación entre las aplicaciones clientes y los sis¬ 
temas de bases de datos. ODBC se basa en las normas 
SQL Interfaz de nivel de llamada (Call-Level Inter- 
face, CLI) desarrolladas por el consorcio industrial 
X/Open y el Grupo SQL Access, pero tienen varias 
extensiones. La API ODBC define una CLI, una defi¬ 
nición de sintaxis SQL y reglas sobre las secuencias 
admisibles de llamadas CLI. La norma también define 
los niveles de conformidad para la CLI y la sintaxis 


526 


CAPÍTULO 21 DESARROLLO DE APLICACIONES Y ADMINISTRACIÓN 


SQL. Por ejemplo, el nivel central de la CL1 tiene 
comandos para conectarse con bases de datos, para pre¬ 
parar y ejecutar sentencias SQL, para devolver resulta¬ 
dos o valores de estado y para administrar transaccio¬ 
nes. El siguiente nivel de conformidad (nivel uno) exige 
el soporte de la recuperación de información de los catá¬ 
logos y otras características que superan la CLI del nivel 
central; el nivel dos exige más características, como la 
capacidad de enviar y recuperar arrays de valores de 
parámetros y de recuperar información de catálogo más 
detallada. 

ODBC permite que un cliente se conecte de manera 
simultánea con varios orígenes de datos y que conmu¬ 
te entre ellos, pero las transacciones en cada uno de ellos 
son independientes entre sí; ODBC no soporta el com¬ 
promiso de dos fases. 

Los sistemas distribuidos ofrecen un entorno más 
general que los sistemas cliente-servidor. El consorcio 
X/Open también ha desarrollado las normas X/Open XA 
para la interoperación de las bases de datos. Estas nor¬ 
mas definen las primitivas de gestión de las transaccio¬ 
nes (como pueden ser el comienzo de las transacciones, 
su compromiso, su anulación y su preparación para el 
compromiso) que deben proporcionar las bases de datos 
que cumplan con la norma; los administradores de las 
transacciones pueden invocar estas primitivas para imple- 
mentar las transacciones distribuidas mediante compro¬ 
miso de dos fases. Las normas XA son independientes 
de los modelos de datos y de las interfaces concretas entre 
los clientes y las bases de datos para el intercambio de 
datos. Por tanto, se pueden utilizar los protocolos XA 
para implementar sistemas de transacciones distribuidas 
en los que una sola transacción pueda tener acceso a bases 
de datos relaciónales y orientadas a objetos y que el admi¬ 
nistrador de transacciones asegure la consistencia global 
mediante el compromiso de dos fases. 

Hay muchos orígenes de datos que no son bases de 
datos relaciónales y, de hecho, puede que no sean ni 
siquiera bases de datos. Ejemplos de esto son los archi¬ 
vos planos y los almacenes de correo electrónico. OLE- 
DB de Microsoft es una API de C++ con objetivos pare¬ 
cidos a los de ODBC, pero para orígenes de datos que 
no son bases de datos y que puede que sólo proporcio¬ 
nen servicios limitados de consulta y de actualización. 
Al igual que ODBC, OLE-DB proporciona estructuras 
para la conexión con orígenes de datos, el inicio de una 
sesión, la ejecución de comandos y la devolución de 
resultados en forma de conjunto de filas, que es un con¬ 
junto de filas de resultados. 

Sin embargo, OLE-DB se diferencia de ODBC en 
varios aspectos. Para dar soporte a los orígenes de datos 
con soporte de características limitadas, las caracterís¬ 
ticas de OLE-DB se dividen entre varias interfaces y 
cada origen de datos sólo puede implementar un sub¬ 
conjunto de esas interfaces. Los programas OLE-DB 
pueden negociar con los orígenes de datos para averi¬ 
guar las interfaces que soportan. En ODBC los coman¬ 
dos siempre están en SQL. En OLE-DB, los comandos 


pueden estar en cualquier lenguaje soportado por el ori¬ 
gen de datos; aunque puede que algunos orígenes de 
datos soporten SQL, o un subconjunto limitado de SQL, 
puede que otros orígenes sólo ofrezcan posibilidades 
sencillas como el acceso a los datos de los archivos pla¬ 
nos, sin ninguna capacidad de consulta. Otra diferencia 
importante de OLE-DB con ODBC es que los conjun¬ 
tos de filas son objetos que pueden compartir varias apli¬ 
caciones mediante la memoria compartida. Los objetos 
conjuntos de filas los puede actualizar una aplicación, 
y a las otras aplicaciones que compartan ese objeto se 
les notificará la modificación. 

La API Objetos activos de datos (Active Data 
Objects, ADO), también creada por Microsoft, ofrece 
una interfaz sencilla de utilizar con la funcionalidad 
OLE-DB, que puede llamarse desde los lenguajes de 
guiones, como VBScript y JScript. 

21.4.3. Normas de las bases de datos 
de objetos 

Hasta ahora las normas en el área de las bases de datos 
orientadas a objetos los han impulsado sobre todo los 
fabricantes de BDOO. El Grupo de gestión de bases de 
datos de objetos (Object Database Management Group, 
ODMG) es un grupo formado por fabricantes de BDOO 
para normalizar los modelos de datos y las interfaces 
de lenguaje con las BDOOs. La interfaz del lenguaje 
C++ especificada por ODMG se estudió en el Capítu¬ 
lo 8. ODMG también ha especificado una interfaz Java 
y una interfaz Smalltalk. 

El Grupo de administración de objetos (Object 
Management Group, OMG) es un consorcio de empre¬ 
sas, formado con el objetivo de desarrollar una arqui¬ 
tectura estándar para las aplicaciones de software dis¬ 
tribuido basadas en el modelo orientado a objetos. OMG 
creó el modelo de referencia. Arquitectura de gestión de 
objetos (Object Management Architecture, OMA). El 
Agente para solicitudes de objetos (Object Request Bro¬ 
ker, ORB) es un componente de la arquitectura OMA 
que proporciona de manera transparente la entrega de 
mensajes a los objetos distribuidos, de modo que la ubi¬ 
cación física del objeto no tiene importancia. La Arqui¬ 
tectura común de agente para solicitudes de objetos 
(Common Object Request Broker Architecture, 
CORBA) proporciona una especificación detallada del 
ORB, e incluye un Lenguaje de descripción de inter¬ 
faces (Interface Description Language, IDL), que se 
utiliza para definir los tipos de datos empleados para el 
intercambio de datos. El IDL ayuda a dar soporte a la 
conversión de datos cuando se intercambian entre sis¬ 
temas con diferentes representaciones de los datos. 

21.4.4. Normas basadas en XML 

Se ha definido una amplia variedad de normas basadas 
en XML (véase el Capítulo 10) para gran número de apli¬ 
caciones. Muchas de estas normas están relacionadas con 
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el comercio electrónico. Entre ellas hay normas pro¬ 
mulgados por consorcios sin ánimo de lucro y esfuerzos 
apoyados por las empresas para crear normas de facto. 
RosettaNet, que pertenece a la primera categoría, utiliza 
normas basadas en XML para facilitar la gestión de las 
cadenas de abastecimiento en las industrias informáticas 
y de tecnologías de la información. Empresas como Com- 
merce One proporcionan sistemas de adquisición basa¬ 
dos en Web, gestión de la cadena de abastecimiento y 
mercados electrónicos (incluidas las subastas en cone¬ 
xión). BizTalk es una infraestructura de esquemas y direc¬ 
trices XML, apoyada por Microsoft. Estos y otros mar¬ 
cos definen catálogos, descripciones de servicios, facturas, 
órdenes de compra, solicitudes de estado de pedidos, 
albaranes de envío y elementos relacionados. 

Los participantes en los mercados electrónicos pue¬ 
den guardar los datos en gran variedad de sistemas de 
bases de datos. Puede que estos sistemas utilicen dife¬ 
rentes modelos, formatos y tipos de datos. Además, pue¬ 
de que haya diferencias semánticas (sistema métrico 
frente a sistema imperial británico, distintas divisas, 
etcétera) en los datos. Las normas para los mercados 
electrónicos incluyen los métodos para envolver cada 
uno de estos sistemas heterogéneos con un esquema 
XML. Estas envolturas XML forman la base de una vis¬ 


ta unificada de los datos para todos los participantes del 
mercado. 

El protocolo simple de acceso a objetos {Simple 
Object Access Protocol, SOAP) es una norma para lla¬ 
madas a procedimientos remotos que utiliza XML para 
codificar los datos (tanto los parámetros como los resul¬ 
tados) y utiliza HTTP como protocolo de transporte; es 
decir, las llamadas a procedimientos se transforman en 
solicitudes HTTP. SOAP está apoyado por el Consor¬ 
cio World Wide Web (World Wide Web Consortium, 
W3C) y está logrando una amplia aceptación en la indus¬ 
tria (incluidos IBM y Microsoft). SOAP puede utilizarse 
en gran variedad de aplicaciones. Por ejemplo, en el 
comercio electrónico entre empresas, las aplicaciones 
que se ejecutan en un sitio pueden tener acceso a los 
datos de otros sitios mediante SOAP. Microsoft ha defi¬ 
nido las normas para el acceso OLAP y para la búsqueda 
de datos con SOAP (OLAP y la búsqueda de datos se 
tratan en el Capítulo 22). 

El lenguaje estándar de consultas de W3C para XML 
se denomina XQuery. Ya en 2001 la norma se hallaba 
en la etapa de pruebas de funcionamiento, y debía estar 
finalizado para finales de ese año. Entre los lenguajes 
de consulta XML anteriores están Quilt (en el que se 
basa XQuery), XML-QL y XQL. 


21.5. COMERCIO ELECTRÓNICO** 


El término comercio electrónico hace referencia al pro¬ 
ceso de llevar a cabo varias actividades relacionadas 
con el comercio por medios electrónicos, principalmente 
por Internet. Entre los tipos de actividades figuran: 

• Actividades previas a la venta, necesarias para 
informar al posible comprador del producto o ser¬ 
vicio que se desea vender. 

• El proceso de venta, que incluye las negociacio¬ 
nes sobre el precio y la calidad del servicio, y otros 
asuntos contractuales. 

• El mercado: cuando hay varios vendedores y varios 
compradores para un mismo producto, un merca¬ 
do, como la bolsa, ayuda a negociar el precio que 
se va a pagar por el producto. Las subastas se uti¬ 
lizan cuando hay un único vendedor y varios com¬ 
pradores, y las subastas inversas se emplean cuan¬ 
do hay un solo comprador y varios vendedores. 

• El pago de la compra. 

• Las actividades relacionadas con la entrega del pro¬ 
ducto o servicio. Algunos productos y servicios 
pueden entregarse por Internet; para otros, Inter¬ 
net sólo se utiliza para facilitar información sobre 
el envío y para realizar un seguimiento de los en¬ 
víos de los productos. 

• Soporte al cliente y servicio postventa. 


Las bases de datos se utilizan ampliamente para 
soportar estas actividades. Para algunas de las activi¬ 
dades el empleo de las bases de datos es directo, pero 
hay aspectos interesantes de desarrollo de aplicaciones 
para las demás actividades. 

21.5.1. Catálogos electrónicos 

Cualquier sitio de comercio electrónico proporciona a 
los usuarios un catálogo de los productos y servicios 
que ofrece. Los servicios facilitados por los catálogos 
electrónicos pueden variar considerablemente. 

Como mínimo, un catálogo electrónico debe propor¬ 
cionar servicios de exploración y de búsqueda para ayu¬ 
dar a los clientes a hallar el producto que buscan. Para 
ayudar en la exploración conviene que los productos estén 
organizados en una jerarquía intuitiva, de modo que unas 
pocas pulsaciones en los hipervínculos puedan llevar a 
los clientes a los productos en los que estén interesados. 
Las palabras clave facilitadas por el cliente (por ejem¬ 
plo, «cámara digital» o «computadora») deben acelerar 
el proceso de búsqueda de los productos solicitados. Los 
catálogos electrónicos también deben proporcionar un 
medio para que los clientes comparen con facilidad las 
alternativas para elegir entre los diferentes productos. 

Los catálogos electrónicos pueden personalizarse 
para los clientes. Por ejemplo, puede que un detallista 
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tenga un acuerdo con una gran empresa para venderle 
algunos productos con descuento. Un empleado de la 
empresa, al examinar el catálogo para adquirir produc¬ 
tos para la empresa, debería ver los precios con el des¬ 
cuento acordado, en vez de con los precios normales. 
Debido a las restricciones legales sobre las ventas de 
algunos tipos de artículos, no se les deberían mostrar a 
los clientes menores de edad, o de ciertos estados o paí¬ 
ses, los artículos que no se les pueden vender legalmente. 
Los catálogos también pueden personalizarse para usua¬ 
rios individuales, de acuerdo con su historial de com¬ 
pras. Por ejemplo, se pueden ofrecer a los clientes fre¬ 
cuentes descuentos especiales en algunos productos. 

El soporte de esa personalización necesita que la infor¬ 
mación de los clientes y la información sobre precios o 
descuentos especiales y sobre restricciones a las ventas 
se guarden en una base de datos. También hay desafíos 
en el soporte de tasas de transacciones muy elevadas, 
que suelen abordarse guardando en la caché los resulta¬ 
dos de las consultas o las páginas Web generadas. 

21.5.2. Mercados 

Cuando hay varios vendedores o varios compradores (o 
ambas cosas) para un producto, los mercados ayudan a 
negociar el precio que debe pagarse por el producto. 
Hay varios tipos diferentes de mercados: 

• En los sistemas de subastas inversas los compra¬ 
dores manifiestan sus necesidades y los vendedo¬ 
res pujan por proporcionar el artículo. El provee¬ 
dor que ofrece el precio más bajo gana la subasta. 
En los sistemas de puja cerrada las pujas no se 
hacen públicas, mientras que en los sistemas de 
puja abierta las pujas sí se hacen públicas. 

• En las subastas hay varios compradores y un solo 
vendedor. En aras de la sencillez, supóngase que 
sólo se vende un ejemplar de cada artículo. Los 
compradores pujan por los artículos que se venden 
y el que puja más alto por un artículo consigue 
comprarlo por el precio de la puja. 

Cuando hay varios ejemplares de un artículo las 
cosas se vuelven más complicadas: supóngase que 
hay cuatro artículos y puede que un comprador 
desee tres ejemplares a 10 € cada uno, mientras que 
otro desea dos copias por 13 € cada una. No es posi¬ 
ble satisfacer ambas pujas. Si los artículos carecen 
de valor si no se venden (por ejemplo, billetes de 
avión, que deben venderse antes de que despegue 
el avión), el vendedor simplemente selecciona un 
conjunto de pujas que maximice los ingresos. En 
caso contrario, la decisión es más complicada. 

• En las bolsas, como puede ser una bolsa de valo¬ 
res, hay varios vendedores y varios compradores. 
Los compradores pueden especificar el precio 
máximo que desean pagar, mientras que los ven¬ 
dedores especifican el precio mínimo que desean. 


Suele haber un creador de mercado que aúna las 
ofertas de compra y de venta y decide el precio de 
cada intercambio (por ejemplo, al precio de la ofer¬ 
ta de venta). 

Hay otros tipos de mercados más complejos. 

Entre los aspectos de las bases de datos relaciona¬ 
dos con el manejo de los mercados figuran: 

• Hay que autentificar a los que realizan las pujas 
antes de permitirles pujar. 

• Las pujas (de compra o de venta) deben registrar¬ 
se de modo seguro en una base de datos. Hay que 
comunicar rápidamente las pujas al resto de las 
personas implicadas en el mercado (como pueden 
ser todos los compradores o todos los vendedores), 
que puede que sean numerosas. 

• Los retrasos en la difusión de las pujas pueden lle¬ 
var a pérdidas financieras para algunos partici¬ 
pantes. 

• Los volúmenes de los intercambios pueden resul¬ 
tar tremendamente grandes en tiempos de volati¬ 
lidad de las bolsas, o hacia el final de las subastas. 
Por tanto, se utilizan para estos sistemas bases de 
datos de muy alto rendimiento con elevados gra¬ 
dos de paralelismo. 

21.5.3. Liquidación de pedidos 

Una vez seleccionados los artículos (quizás mediante 
un catálogo electrónico) y determinado el precio (aca¬ 
so mediante un mercado electrónico), hay que liquidar 
el pedido. La liquidación implica el pago y la entrega 
de las mercancías. 

Una manera sencilla pero poco segura de pagar elec¬ 
trónicamente consiste en enviar el número de una tarje¬ 
ta de crédito. Hay dos problemas principales. En primer 
lugar, es posible el fraude con las tarjetas de crédito. Cuan¬ 
do un comprador paga mercancías físicas las empresas 
pueden asegurarse de que la dirección de entrega coin¬ 
cide con la del titular de la tarjeta, de modo que nadie 
más reciba la mercancía, pero para las mercan-cías entre¬ 
gadas de manera electrónica no es posible realizar esa 
comprobación. En segundo lugar, hay que confiar en que 
el vendedor sólo facture el artículo acordado y en que no 
pase el número de la tarjeta de crédito a personas no auto¬ 
rizadas que lo puedan utilizar de manera no adecuada. 

Se dispone de varios protocolos para los pagos segu¬ 
ros que evitan los dos problemas mencionados. Ade¬ 
más, proporcionan una mayor intimidad, ya que no hay 
que dar al vendedor datos innecesarios del comprador 
y no se le facilitan a la compañía de la tarjeta de crédi¬ 
to información innecesaria de los artículos comprados. 
Toda la información transmitida debe cifrarse de modo 
que nadie que intercepte los datos por la red pueda ave¬ 
riguar su contenido. El cifrado con claves pública y pri¬ 
vada se utiliza mucho para esta tarea. 
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Los protocolos también deben evitar los ataques de 
personas intermedias, en los que alguien puede suplan¬ 
tar al banco o a la compañía de la tarjeta de crédito, o 
incluso al vendedor o al comprador y sustraer informa¬ 
ción secreta. La suplantación puede realizarse pasando 
una clave falsa como si fuera la clave pública de otra 
persona (el banco, la compañía de la tarjeta de crédito, 
el comerciante o el comprador). La suplantación se evi¬ 
ta mediante un sistema de certificados digitales, en el 
que las claves públicas vienen firmadas por una agencia 
de certificación cuya clave pública es bien conocida (o 
que, a su vez, tiene su clave pública certificada por otra 
agencia de certificación, y así hasta llegar a una clave 
que sea bien conocida). A partir de la clave pública bien 
conocida el sistema puede autentificar las otras claves 
comprobando los certificados en una secuencia inversa. 


El protocolo transacciones electrónicas seguras 
(Secure Electronic Transaction, SET) es uno de los 

protocolos de pago seguro. El protocolo necesita varias 
rondas de comunicación entre el comprador, el vende¬ 
dor y el banco para garantizar la seguridad de la tran¬ 
sacción. 

También hay sistemas que ofrecen más anonima¬ 
to, parecido al proporcionado por el dinero físico en 
efectivo. El sistema de pagos DigiCash es uno de esos 
sistemas. Cuando se realiza un pago en estos sistemas 
no es posible identificar al comprador. Sin embargo, 
la identificación del comprador resulta muy sencilla 
con las tarjetas de crédito, e incluso en el caso de SET 
es posible identificar al comprador con la colabora¬ 
ción de la compañía emisora de la tarjeta de crédito o 
del banco. 


21.6. SISTEMAS HEREDADOS 


Los sistemas heredados son sistemas de generaciones 
anteriores que son incompatibles con las normas y sis¬ 
temas de la generación actual. Puede que estos sistemas 
todavía contengan datos valiosos y den soporte a apli¬ 
caciones críticas. Los sistemas heredados de hoy en día 
suelen ser los construidos con tecnologías como las 
bases de datos que utilizan los modelos de datos de red 
o jerárquico o utilizan Cobol y sistemas de archivos sin 
bases de datos. 

El traspaso de las aplicaciones heredadas a entornos 
más modernos suele resultar costoso tanto en términos 
de tiempo como de dinero, dado que suelen ser de tama¬ 
ño muy grande, con millones de líneas de código desa¬ 
rrolladas por equipos de programadores a lo largo de 
varias décadas. 

Por eso es importante dar soporte a estos sistemas 
de generaciones anteriores, o heredados, y facilitar su 
interoperatividad con los sistemas más modernos. Un 
enfoque empleado para interoperar entre las bases de 
datos relaciónales y las bases de datos heredadas es 
crear una capa, denominada envoltura, por encima de 
los sistemas heredados que pueda hacer que el sistema 
heredado parezca una bases de datos relacional. Puede 
que la envoltura ofrezca soporte para ODBC u otras nor¬ 
mas de interconexión como OLE-DB, que puede utili¬ 
zarse para consultar y actualizar el sistema heredado. 
La envoltura es responsable de la conversión de las con¬ 
sultas y actualizaciones relaciónales en consultas y 
actualizaciones del sistema heredado. 

Cuando una organización decide sustituir un siste¬ 
ma heredado por otro nuevo debe seguir un proceso 
denominado ingeniería inversa, que consiste en repa¬ 
sar el código del sistema heredado para obtener el dise¬ 
ño de los esquemas del modelo de datos requerido (como 
puede ser el modelo E-R o un modelo de datos orien¬ 
tado a los objetos). La ingeniería inversa también exa¬ 


mina el código para averiguar los procedimientos y los 
procesos que se implementan con objeto de obtener un 
modelo de alto nivel del sistema. La ingeniería inversa 
es necesaria porque los sistemas heredados no suelen 
tener documentación de alto nivel de sus esquemas ni 
del diseño global de sus sistemas. Al presentarse el dise¬ 
ño de un nuevo sistema se repasa el diseño de modo que 
pueda mejorarse en lugar de volver a implementarlo tal 
como estaba. Se necesita una amplia labor de codifica¬ 
ción para dar soporte a toda la funcionalidad (como pue¬ 
den ser las interfaces de usuario y los sistemas de infor¬ 
mación) que proporcionaba el sistema heredado. El 
proceso completo se denomina reingeniería. 

Cuando se ha creado y probado el sistema nuevo hay 
que llenarlo con los datos del sistema heredado y todas 
las actividades posteriores se deben realizar en el siste¬ 
ma nuevo. No obstante, la transición abrupta al sistema 
nuevo, que se denomina enfoque gran explosión, con¬ 
lleva varios riesgos. En primer lugar, puede que los usua¬ 
rios no estén familiarizados con las interfaces del siste¬ 
ma nuevo. En segundo lugar, puede haber fallos o 
problemas de rendimiento en el sistema nuevo que no 
se hayan descubierto al probarlo. Estos problemas pue¬ 
den provocar grandes pérdidas a las empresas, dado que 
puede resultar gravemente afectada su capacidad para 
realizar transacciones críticas como las compras y las 
ventas. En algunos casos extremos se ha llegado a aban¬ 
donar el sistema nuevo y se ha vuelto a utilizar el sis¬ 
tema heredado después de que fallara el intento de cam¬ 
bio. 

Un enfoque alternativo, denominado enfoque ¡ncre- 
mental, sustituye la funcionalidad del sistema here¬ 
dado de manera incremental. Por ejemplo, puede que 
las nuevas interfaces de usuario se utilicen con el sis¬ 
tema antiguo en el dorsal, o viceversa. Otra opción es 
utilizar el sistema nuevo sólo para algunas funcionali- 
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dades que puedan desgajarse del sistema heredado. En 
cualquier caso, los sistemas heredados y los nuevos 
coexisten durante algún tiempo. Por tanto, existe una 
necesidad de desarrollo y empleo de envolturas del sis¬ 


tema heredado para proporcionar la funcionalidad 
requerida para interoperar con el sistema nuevo. Este 
enfoque, por tanto, tiene asociado un coste de desa¬ 
rrollo superior. 


21.7. RESUMEN 


• Los exploradores Web se han constituido en la inter¬ 
faz de usuario con las bases de datos más utilizada. 
HTML proporciona la posibilidad de definir las inter¬ 
faces que combinan los hipervínculos con los formu¬ 
larios. Los exploradores Web se comunican con los 
servidores Web mediante el protocolo HTTP. Los ser¬ 
vidores Web pueden pasar las solicitudes a los pro¬ 
gramas de las aplicaciones y devolver los resultados 
al explorador. 

• Hay varios lenguajes de guiones del lado del cliente 
(JavaScript es el más utilizado) que proporcionan una 
mayor interacción con el usuario en el extremo del 
explorador. 

• Los servidores Web ejecutan los programas de las 
aplicaciones para implementar la funcionalidad de¬ 
seada. Las servlets son un mecanismo muy utilizado 
para escribir programas de aplicaciones que se eje¬ 
cutan como parte del proceso del servidor Web para 
reducir las sobrecargas. También hay muchos len¬ 
guajes de guiones del lado del servidor que interpre¬ 
ta el servidor Web y proporcionan la funcionalidad 
de los programas de aplicaciones como parte del ser¬ 
vidor Web. 

• El ajuste de los parámetros del sistema de bases de 
datos, así como el diseño de nivel superior de la base 
de datos (como pueden ser el esquema, los índices y 
las transacciones) resultan importantes para lograr 
un buen rendimiento. La mejor forma de realizar el 
ajuste es identificar los cuellos de botella y elimi¬ 
narlos. 

• Las pruebas de rendimiento desempeñan un papel 
importante en las comparaciones entre sistemas de 
bases de datos, especialmente a medida que cumplen 
cada vez más las normas. El conjunto de pruebas TPC 
se utiliza mucho y las diferentes pruebas TPC resul¬ 


tan útiles para la comparación del rendimiento de las 
bases de datos con diferentes cargas de trabajo. 

• Las normas son importantes debido a la complejidad 
de los sistemas de bases de datos y a la necesidad de 
interoperatividad. Hay normas formales para SQL. Las 
normas de facto, como ODBC y JDBC, y las normas 
adoptadas por gmpos de empresas, como CORB A, han 
desempeñado un papel importante en el crecimiento 
de los sistemas de bases de datos cliente-servidor. Hay 
grupos de empresas desarrollando normas para las 
bases de datos orientadas a objetos, como ODMG. 

• Los sistemas de comercio electrónico se están con¬ 
virtiendo con rapidez en la parte principal del modo 
en que se realiza el comercio. Hay varios aspectos de 
las bases de datos en los sistemas de comercio elec¬ 
trónico. La administración de los catálogos, especial¬ 
mente su personalización, se realiza con bases de datos. 
Los mercados electrónicos ayudan a fijar el precio de 
los productos mediante subastas, subastas inversas o 
bolsas. Se necesitan sistemas de bases de datos de alto 
rendimiento para manejar este intercambio. Los pedi¬ 
dos se liquidan mediante sistemas de pago electróni¬ 
co, que también necesitan sistemas de bases de datos 
de alto rendimiento para manejar tasas de transaccio¬ 
nes muy elevadas. 

• Los sistemas heredados son sistemas basados en tec¬ 
nologías de generaciones anteriores como las bases 
de datos no relaciónales o, incluso, directamente en 
sistemas de archivos. Suele ser importante el esta¬ 
blecimiento de las interfaces entre los sistemas here¬ 
dados y los sistemas de última generación cuando eje¬ 
cutan sistemas de misión crítica. La migración desde 
los sistemas heredados a los sistemas de última gene¬ 
ración debe realizarse con cuidado para evitar inte¬ 
rrupciones, que pueden resultar muy costosas. 


TÉRMINOS DE REPASO 


• Ajuste del esquema 

• Ajuste del hardware 

• Ajuste de los índices 

• Ajuste del rendimiento 

• Ajuste de las transacciones 

• Applets 


• Catálogos electrónicos 

• Certificados digitales 

• Clases de aplicaciones de bases de datos 

• Cookie 

• Comercio electrónico 

• Cuellos de botella 
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• Guiones del lado cliente 

• Guiones del lado del servidor 

• Hipervínculos 

• Ingeniería inversa 

• Interacciones Web por segundo 

• Interfaces Web con las bases de datos 

• Interfaz de pasarela común (Common Gateway Inter- 
face, CGI) 

• Lenguaje de guiones del lado del cliente 

• Lenguaje de marcas de hipertexto (HyperTextMar- 
kup Language, HTML) 

• Liquidación de pedidos 

• Localizador uniforme de recursos (Uniform resource 
locator, URL) 

• Mantenimiento diferido de vistas 

• Mantenimiento inmediato de vistas 

• Mejora de la orientación del conjunto 

• Mercados 

— Bolsas 

— Subastas 

— Subastas inversas 

• Normalización 

— Normas anticipativas 

— Normas de facto 

— Normas formales 

— Normas reaccionarias 

• Normas basadas en XML 

• Normas de bases de datos de objetos 

— CORBA 

— ODMG 

• Normas de conectividad para bases de datos 

— Normas X/Open XA 


— ODBC 

— OLE-DB 

• Parámetros ajustables 

• Procesamiento de transacciones por minilotes 

• Protocolo de transferencia de hipertexto (HyperText 
Transfer Protocol, HTTP) 

• Pruebas de BDOO 

— 001 

— 007 

• Pruebas de rendimiento 

• Pruebas TPC 

— TPC-A 

— TPC-B 

— TPC-C 

— TPC-D 

— TPC-R 

— TPC-H 

— TPC-W 

• Regla de los cinco minutos 

• Regla del minuto 

• Reingeniería 

• Servidores Web 

• Servlets 

• Sesión 

• Simulación del rendimiento 

• Sin conexión 

• Sistemas de colas 

• Sistemas heredados 

• Tiempo hasta su finalización 

• Tiempo de servicio 

• Vistas materializadas 


EJERCICIOS 


21.1 ¿Cuál es la razón principal por la que los servlets 
dan mejor rendimiento que los programas que utili¬ 
zan la interfaz de pasarela común (common gateway 
interface, CGI), pese a que los programas Java sue¬ 
len ejecutarse más lentamente que los programas C 
o C++? 

21.2 Indíquense algunas de las ventajas y de los inconve¬ 
nientes de los protocolos sin conexión frente a los pro¬ 
tocolos que mantienen las conexiones. 

21.3 Indíquense tres maneras en que se puede utilizar el 
almacenamiento en caché para acelerar el rendimien¬ 
to de los servidores Web. 


21.4 a. ¿Cuáles son los tres niveles principales en los que 

se puede ajustar un sistema de bases de datos para 
mejorar su rendimiento? 

b. Dense dos ejemplos del modo en que se puede rea¬ 
lizar el ajuste para cada uno de los niveles. 

21.5 ¿Cuál es el motivo para separar una transacción de lar¬ 
ga duración en una serie de transacciones más breves? 
¿Qué problemas pueden surgir como consecuencia y 
cómo pueden evitarse? 

21.6 Supóngase que un sistema ejecuta tres tipos de tran¬ 
sacciones. Las transacciones de tipo A se ejecutan a 
razón de 50 por segundo, las transacciones de tipo B 
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se ejecutan a 100 por segundo y las transacciones de 
tipo C se ejecutan a 200 por segundo. Supóngase que 
la mezcla de transacciones tiene un 25 por ciento del 
tipo A, otro 25 por ciento del tipo B y un 50 por cien¬ 
to del tipo C. 

a. ¿Cuál es el flujo promedio de transacciones del sis¬ 
tema, suponiendo que no hay interferencia entre las 
transacciones? 

b. ¿Qué factores pueden generar interferencias entre 
las transacciones de los diferentes tipos, haciendo 
que el flujo calculado sea incorrecto? 

21.7 Supóngase que el precio de la memoria cae a la mitad 
y la velocidad de acceso al disco (número de accesos 
por segundo) se dobla mientras el resto de los facto¬ 
res permanecen iguales. ¿Cuál sería el efecto de este 


cambio en las reglas de los cinco minutos y del mi¬ 
nuto? 

21.8 Indíquense algunas de las características de las prue¬ 
bas TPC que ayudan a hacerlas medidas realistas y dig¬ 
nas de confianza. 

21.9 ¿Por qué se sustituyó al índice TPC-D por los pruebas 
TPC-H y TPC-R? 

21.10 Indíquense algunas ventajas e inconvenientes de las 
normas anticipativas frente a las normas reaccionarias. 

21.11 Supóngase que alguien suplanta a una empresa y obtie¬ 
ne un certificado de una autoridad emisora de certifi¬ 
cados. ¿Cuál es el efecto sobre las cosas (como las órde¬ 
nes de compra o los programas) certificadas por la 
empresa suplantada y sobre las cosas certificadas por 
otras empresas? 


SUGERENCIAS DE PROYECTOS 


Cada uno de los que aparecen a continuación es un pro¬ 
yecto de grandes dimensiones, que puede ser un pro¬ 
yecto de un semestre de duración realizado por un gru¬ 
po de estudiantes. La dificultad de cada proyecto puede 
ajustarse fácilmente añadiendo o eliminando caracte¬ 
rísticas. 

Proyecto 21.1 Considérese el esquema E-R del Ejer¬ 
cicio 2.7 (Capítulo 2), que representa la información 
de los equipos de una liga. Diséñese e impleménte- 
se un sistema basado en la Web para introducir, 
actualizar y examinar los datos. 

Proyecto 21.2 Diséñese e impleméntese un sistema de 
carro de la compra que permita a los compradores 
reunir artículos en un carro de la compra (se puede 
decidir la información que se proporciona de cada 
artículo) y comprarlos todos juntos. Se puede exten¬ 
der y utilizar el esquema E-R del Ejercicio 2.12 del 
Capítulo 2. Conviene comprobar la disponibilidad 
del artículo y tratar los artículos no disponibles del 
modo que se considere adecuado. 

Proyecto 21.3 Diséñese e impleméntese un sistema 
basado en la Web para registrar la información sobre 
las matrículas y los cursos de los estudiantes para 
los cursos de una universidad. 

Proyecto 21.4 Diséñese e impleméntese un sistema que 
permita el registro de la información de rendimien¬ 
to de los cursos (concretamente, las notas dadas a 
cada estudiante en cada trabajo o examen de cada 
curso, y el cálculo de una suma [ponderada] de las 
notas para obtener las notas totales del curso). El 
número de trabajos o exámenes no debe estar pre¬ 
definido; es decir, se pueden añadir más trabajos o 
exámenes en cualquier momento. El sistema tam¬ 
bién debe soportar la separación, permitiendo que 
se especifiquen separadores para varios niveles. 


Puede que también se desee integrarlo con el sis¬ 
tema de matrícula de los estudiantes del Proyecto 21.3 
(que quizás implemente otro equipo de proyecto). 

Proyecto 21.5 Diséñese e impleméntese un sistema 
basado en la Web para la reserva de aulas en la uni¬ 
versidad. Se debe soportar la reserva periódica (días 
y horas fijas cada semana para un semestre comple¬ 
to). También debe soportarse la cancelación de cla¬ 
ses concretas de una reserva periódica. 

Puede que también se desee integrarlo con el sis¬ 
tema de matrícula de estudiantes del Proyecto 21.3 
(que quizás implemente otro equipo de proyecto) de 
modo que las aulas puedan reservarse para cursos y 
las cancelaciones de una clase o de más clases pue¬ 
dan anotarse en una sola interfaz, se reflejen en la 
reserva de aulas y se comuniquen a los estudiantes 
por correo electrónico. 

Proyecto 21.6 Diséñese e impleméntese un sistema 
para gestionar exámenes multiopción en línea. Se 
debe soportar el aporte distribuido de preguntas (por 
los profesores ayudantes, por ejemplo), la edición 
de las preguntas por quien esté a cargo del curso y 
la creación de exámenes a partir del conjunto de pre¬ 
guntas disponible. También se debe poder adminis¬ 
trar los exámenes en línea, bien a una hora fija para 
todos los estudiantes o a cualquier hora, pero con un 
límite de tiempo desde el comienzo hasta el final 
(hay que soportar una de las opciones o las dos) y 
dar a los estudiantes información sobre su puntua¬ 
ción al final del tiempo concedido. 

Proyecto 21.7 Diséñese e impleméntese un sistema 
para gestionar el servicio de correo electrónico de 
los clientes. El correo entrante va a un buzón común. 
Hay una serie de agentes de servicio para los clien¬ 
tes que responden el correo electrónico. Si el men¬ 
saje es parte de una serie de respuestas (que se siguen 
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mediante el campo responder a del correo electró¬ 
nico) es preferible que responda el mensaje el mis¬ 
mo agente que lo respondió anteriormente. El siste¬ 
ma debe realizar un seguimiento de todo el correo 
entrante y de las respuestas, de modo que los agen¬ 
tes puedan ver el historial de preguntas de cada clien¬ 
te antes de responder a los mensajes. 

Proyecto 21.8 Diséñese e impleméntese un mercado 
electrónico sencillo en el que los artículos puedan 
clasificarse para su compra o venta en varias cate¬ 
gorías (que deben formar una jerarquía). Puede que 
también se desee soportar los servicios de alerta, en 
los que un usuario puede registrar su interés por los 
artículos de una categoría concreta, quizás con otras 
restricciones añadidas, sin anunciar su interés de 
manera pública y se le notifica cuando uno de esos 
artículos se ofrece a la venta. 

Proyecto 21.9 Diséñese e impleméntese un sistema de 
grupos de noticias basado en la Web. Los usuarios 
deben poder suscribirse a los grupos de noticias y 
explorar los artículos de esos grupos. El sistema hace 
un seguimiento de los artículos que el usuario ha leí¬ 
do, de modo que no vuelvan a exhibirse. También 
permite la búsqueda de artículos antiguos. 

Puede que también se desee ofrecer un servicio 
de clasificación de los artículos, de modo que los 
artículos con puntuación elevada se destaquen y se 
permita al lector ocupado saltarse los artículos con 
baja puntuación. 


Proyecto 21.10 Diséñese e impleméntese un sistema 
basado en la Web para gestionar una clasificación 
deportiva. Se registra mucha gente y puede que se 
les dé alguna clasificación inicial (quizás con base 
en sus resultados anteriores). Cualquiera puede desa¬ 
fiar a un partido a cualquier otro y las clasificacio¬ 
nes se ajustan de acuerdo con los resultados. 

Un sistema sencillo para ajustar las clasificacio¬ 
nes simplemente pasa al ganador por delante del per¬ 
dedor en la clasificación, en caso de que el ganador 
estuviera por detrás. Se puede intentar inventar sis¬ 
temas de ajustes de la clasificación más complica¬ 
dos. 

Proyecto 21.11 Diséñese e impleméntese un servicio 
de listados de publicaciones. El servicio debe per¬ 
mitir la introducción de información sobre las publi¬ 
caciones, como pueden ser título, autores, año en 
que apareció la publicación, páginas, etcétera. Los 
autores deben ser una entidad separada con atribu¬ 
tos como nombre, institución, departamento, correo 
electrónico, dirección y página Web. 

La aplicación debe soportar varias vistas de los 
mismos datos. Por ejemplo, se deben facilitar todas 
las publicaciones de un autor dado (ordenadas por 
año, por ejemplo), o todas las publicaciones de los 
autores de una institución o departamento dado. Tam¬ 
bién se debe soportar la búsqueda por palabras cla¬ 
ve, tanto en la base de datos global como en cada 
una de las vistas. 


NOTAS BIBLIOGRÁFICAS 


La información sobre los servlets, incluidos los tuto- 
riales, las especificaciones de las normas y el software, 
está disponible en java.sun.com/products/servlet. La 
información sobre JSP está disponible en java.sun.com/ 
products/jsp. 

Una de las primeras propuestas de pruebas de cali¬ 
dad de sistemas de bases de datos (el índice Wisconsin) 
la realizaron Bitton et al. [1983]. Los pruebas TPC-A,- 
B y -C se describen en Gray [1991], Una versión en 
línea de todas las descripciones de los pmebas TPC, así 
como de los resultados de estas pruebas, está disponi¬ 
ble en World Wide Web en el URL www.tpc.org; el sitio 
también contiene información actualizada sobre nuevas 
propuestas de pruebas. Poess y Floyd [2000] da una 
introducción de los pruebas TPC-H, TPC-R y TPC-W. 
El índice OOl para BDOOs se describe en Cattell y 
Skeen [1992]; el índice 007 se describe en Carey et al. 
[1993], 

Kleinrock [1975] y Kleinrock [1976] es un libro de 
texto popular de dos volúmenes sobre la teoría de colas. 

Shasha [1992] ofrece una buena introducción al ajus¬ 
te de bases de datos. O’Neil y O’Neil [2000] ofrece un 


tratamiento de libro de texto de muy buena calidad de 
la medida del rendimiento y de su ajuste. Las reglas de 
los cinco minutos y del minuto se describen en Gray y 
Putzolu [1987] y en Gray y Graefe [1997]. Brown et al. 
[1994] describe una aproximación al ajuste automati¬ 
zado. La selección de índices y de vistas materializadas 
se abordan en Ross et al. [1996], Labio et al. [1997], 
Gupta [1997], Chaudhuri y Narasayya [1997], Agrawal 
et al. [2000] y Mistry et al. [2001]. 

La norma nacional americana SQL-86 se describe 
en ANSI [1986]. La definición de la Arquitectura de 
aplicaciones de sistemas de IBM de SQL se especifica 
en IBM [1987]. Las normas para SQL-89 y para SQL- 
92 están disponibles como ANSI [1989] y como ANSI 
[1992], respectivamente. Para hallar referencias a la nor¬ 
ma SQL: 1999 véanse las notas bibliográficas del Capí¬ 
tulo 9. 

La interfaz del nivel de llamada X/Open SQL se defi¬ 
ne en X/Open [1993]; la API ODBC se describe en 
Microsoft [1997] y en Sanders [1998]. La interfaz 
X/Open XA se define en X/Open [1991]. Se puede hallar 
más información sobre ODBC, OLE-DB y ADO en el 
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sitio Web www.microsoft.com/data, y en varios libros 
sobre el tema que pueden hallarse mediante www.ama- 
zon.com. La norma ODMG 3.0 se define en Cattell 
[2000]. La revista SigmodRecord de ACM , que se publi¬ 
ca trimestralmente, tiene una sección fija sobre las nor¬ 
mas de bases de datos, incluidas las normas de las prue¬ 
bas de calidad. 

Se halla disponible en línea gran cantidad de infor¬ 
mación sobre las normas basadas en XML. Se puede 
usar cualquier motor de búsqueda Web como Google 


para obtener información más detallada y actualizada 
sobre XML y otras normas. 

Loeb [1998] ofrece una detallada descripción de las 
transacciones electrónicas seguras. La reingeniería de 
procesos industriales se trata en Cook [1996]. Kirchmer 
[1999] describe la implementación de aplicaciones 
mediante software estándar como los paquetes Enter¬ 
prise Resource Planning (ERP). Umar [1997] trata la 
reingeniería y aspectos del trabajo con sistemas here¬ 
dados. 


HERRAMIENTAS 


Hay muchas herramientas de desarrollo Web que sopor¬ 
tan conectividad de bases de datos mediante servlets, 
JSP, JavaScript u otros mecanismos. A continuación se 
citan algunos de los más conocidos: Java SDK de Sun 
(java.sun.com), Tomcat (jakarta.apache.org) y servidor 
Web de Apache (apache.org), WebSphere de IBM 
(www.software.ibm.com), las herramientas ASP de 


Microsoft (www.microsoft.com), los productos Coldfu- 
sion y JRun de Allaire (www.allaire.com), Resin de Cau¬ 
cho (www.caucho.com) y Zope (www.zope.org). Algu¬ 
nos de ellos, como Apache, son gratis para cualquier tipo 
de uso y algunos son gratis para uso no comercial o per¬ 
sonal, mientras que otros hay que pagarlos. Hay que ver 
los sitios Web respectivos para obtener más información. 
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CONSULTAS AVANZADAS 
Y RECUPERACIÓN DE LA INFORMACIÓN 


L as empresas han comenzado a aprovechar los cada vez más numerosos datos en línea 
para tomar mejores decisiones sobre sus actividades, como los artículos que deben tener 
en inventario y el modo de dirigirse mejor a los clientes para aumentar las ventas. Muchas 
de las consultas, sin embargo, son bastante complejas y algunos tipos de información no pue¬ 
den extraerse ni siguiera empleando SQL. 

Hay disponibles varias técnicas y herramientas para ayudar en la toma de decisiones. Varias 
herramientas para el análisis de datos permiten a los analistas ver los datos de diferentes for¬ 
mas. Otras herramientas de análisis realizan un cálculo previo de resúmenes de cantidades muy 
grandes de datos con objeto de dar respuestas rápidas a las consultas. La norma SQL: 1999 con¬ 
tiene ahora estructuras adicionales para soportar el análisis de datos. Otro enfoque para obte¬ 
ner información de los datos es utilizar la recopilación de datos, que pretende detectar varios 
tipos de estructuras en grandes volúmenes de datos. La recopilación de datos complementa 
varios tipos de técnicas estadísticas con objetivos parecidos. 

Los datos de texto también han crecido de manera explosiva. Los datos de texto no están 
estructurados, a diferencia de los datos rígidamente estructurados de las bases de datos rela¬ 
ciónales. La consulta de los datos de texto no estructurados se denomina recuperación de la 
información. Los sistemas de recuperación de la información tienen mucho en común con los 
sistemas de bases de datos, en particular, el almacenamiento y la recuperación de los datos guar¬ 
dados en almacenamientos secundarios. No obstante, el énfasis en el campo de los sistemas de 
información es diferente del de los sistemas de bases de datos y se concentra en aspectos como 
las consultas basadas en palabras clave, la importancia de los documentos para la consulta, y 
el análisis, la clasificación y el indexado de los documentos. 

Este capítulo trata la ayuda a la toma de decisiones, incluidos el procesamiento analítico en 
línea, la recopilación de datos y la recuperación de la información. 


22.1. SISTEMAS DE AYUDA A LA TOMA DE DECISIONES 


Las aplicaciones de bases de datos pueden clasificarse 
grosso modo en procesamiento de transacciones y ayu¬ 
da a la toma de decisiones, como ya se ha visto en el 
Apartado 21.3.2. Los sistemas de procesamiento de tran¬ 
sacciones se utilizan mucho hoy en día y las empresas 
han acumulado una enorme cantidad de información 
generada por esos sistemas. 

Por ejemplo, las bases de datos de las empresas sue¬ 
len contener enormes cantidades de información sobre 
los clientes y las transacciones. El tamaño del almace¬ 
namiento de la información necesario puede llegar a 
varios centenares de gigabytes o, incluso, a los teraby- 
tes, para las cadenas de grandes almacenes. La infor¬ 
mación de las transacciones de un gran almacén puede 
incluir el nombre o identificador (como puede ser el 
número de la tarjeta de crédito) del cliente, los artícu¬ 
los adquiridos, el precio pagado y las fechas en que se 
realizaron las compras. La información sobre los ar¬ 
tículos adquiridos puede incluir el nombre del artículo, 
el fabricante, el número del modelo, el color y la talla. 


La información sobre los clientes puede incluir su his¬ 
torial de crédito, sus ingresos anuales, su domicilio, su 
edad e, incluso, su nivel académico. 

Estas bases de datos de gran tamaño pueden resul¬ 
tar minas de información para adoptar decisiones empre¬ 
sariales, como los artículos que debe haber en inventa¬ 
rio y los descuentos que hay que ofrecer. Por ejemplo, 
puede que una cadena de grandes almacenes note un 
aumento súbito de las compras de camisas de franela 
en la Sierra de Guadarrama, darse cuenta de que hay 
una tendencia y comenzar a almacenar un mayor núme¬ 
ro de esas camisas en las tiendas de esa zona. O puede 
que una empresa automovilística descubra, al consultar 
su base de datos, que la mayor parte de los coches depor¬ 
tivos de pequeño tamaño los compran mujeres jóvenes 
cuyos ingresos anuales superan los 50.000 €. Puede que 
la empresa dirija su publicidad para que atraiga más 
mujeres de esas características a que compren coches 
deportivos de pequeño tamaño y evite desperdiciar dine¬ 
ro intentando atraer a otras categorías de consumidores 
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para que compren esos coches. En ambos casos la 
empresa ha identificado pautas de comportamiento de 
los consumidores y las ha utilizado para adoptar deci¬ 
siones empresariales. 

El almacenamiento y recuperación de los datos para la 
ayuda a la toma de decisiones plantea varios problemas: 

• Aunque muchas consultas para ayuda a la toma de 
decisiones pueden escribirse en SQL, otras no pue¬ 
den expresarse en SQL o no pueden hacerlo con 
facilidad. En consecuencia, se han propuesto varias 
extensiones de SQL para facilitar el análisis de los 
datos. El área de procesamiento analítico en línea 
{Online Analy tic al Processing, OLAP) trata de las 
herramientas y de las técnicas para el análisis de 
los datos que pueden dar respuestas casi instantá¬ 
neas a las consultas que soliciten datos resumidos, 
aunque la base de datos sea extremadamente gran¬ 
de. En el Apartado 22.2 se estudian las extensio¬ 
nes de SQL para el análisis de datos y las técnicas 
para el procesamiento analítico en línea. 

• Los lenguajes de consulta de bases de datos no resul¬ 
tan adecuados para el rendimiento de los análisis 
estadísticos detallado de los datos. Hay varios paque¬ 
tes, como SAS y S++, que ayudan en el análisis esta¬ 
dístico. A estos paquetes se les han añadido interfa¬ 
ces con las bases de datos para permitir que se 
almacenen en la base de datos grandes volúmenes 
de datos y se recuperen de manera eficiente para su 
análisis. El campo del análisis estadístico es una gran 
disciplina por sí misma, véanse las referencias en las 
notas bibliográficas para obtener más información. 


• Las técnicas de búsqueda de información inten¬ 
tan descubrir de manera automática las reglas y 
las pautas estadísticas de los datos. El campo de 
la recopilación de datos combina las técnicas de 
búsqueda de información creadas por los investi¬ 
gadores en inteligencia artificial y los expertos en 
análisis estadístico con las técnicas de implemen- 
tación eficiente que permiten utilizarlas en bases 
de datos extremadamente grandes. El Apartado 
22.3 estudia la recopilación de datos. 

• Las grandes empresas tienen varios orígenes de 
datos que necesitan utilizar para adoptar decisio¬ 
nes empresariales. Los orígenes pueden almace¬ 
nar los datos según diferentes esquemas. Por moti¬ 
vos de rendimiento (así como por motivos de 
control de la organización) los orígenes de datos 
no suelen permitir que otras partes de la empre¬ 
sa recuperen datos a petición. 

Para ejecutar de manera eficiente las consultas 
sobre datos tan diferentes las empresas han creado 
almacenes de datos. Los almacenes de datos reú¬ 
nen los datos de varios orígenes bajo un esquema 
unificado en un solo sitio. Por tanto, ofrecen al usua¬ 
rio una sola interfaz uniforme para los datos. Los 
problemas de la creación y mantenimiento de los 
almacenes de datos se estudian en el Apartado 22.4. 

El área de ayuda a la toma de decisiones puede con¬ 
siderarse que abarca todas las áreas anteriores, aunque 
algunas personas utilizan el término en un sentido más 
restrictivo que excluye el análisis estadístico y la reco¬ 
pilación de datos. 


22.2. ANÁLISIS DE DATOS Y OLAP 


Aunque es mejor dejar el análisis estadístico complejo 
a los paquetes estadísticos, las bases de datos deben 
soportar las formas sencillas, utilizadas frecuentemen¬ 
te, de análisis estadístico. Dado que los datos almace¬ 
nados en las bases de datos suelen ser de gran volumen, 
hay que resumirlos de algún modo si hay que obtener 
información que puedan utilizar los usuarios. 

Las herramientas OLAP soportan el análisis inte¬ 
ractivo de la información de resumen. Se han desa¬ 
rrollado varias extensiones de SQL para soportar las 
herramientas OLAP. Hay muchas tareas utilizadas con 
frecuencia que no pueden realizarse empleando las 
facilidades básicas de agregación y agrupamiento de 
SQL. Entre los ejemplos se hallan la búsqueda de per- 
centiles, las distribuciones acumulativas o los agrega¬ 
dos sobre ventanas deslizantes de datos ordenados 
secuencialmente. Recientemente se han propuesto 
varias extensiones de SQL para soportar estas tareas 
y se han implementado en productos como Oracle y 
DB2 de IBM. 


22.2.1. Procesamiento analítico en línea 

El análisis estadístico suele necesitar el agrupamiento 
de varios atributos. Considérese una aplicación en que 
una tienda desea averiguar las prendas que son más 
populares. Supóngase que las prendas están caracteri¬ 
zadas por su nombre de artículo, su color y su talla y 
que se tiene la relación ventas con el esquema ventas 
{nombre-artículo, color, talla, número). Supóngase que 
nombre-artículo puede adoptar los valores (falda, ves¬ 
tido, camisa, pantalón), color puede adoptar los valo¬ 
res (oscuro, pastel, blanco) y talla puede adoptar los 
valores (pequeña, mediana, grande). 

Dada una relación utilizada para el análisis de datos 
se pueden identificar algunos de sus atributos como atri¬ 
butos de medida, ya que miden algún valor y pueden 
agregarse. Por ejemplo, el atributo número de la relación 
ventas es un atributo de medida, ya que mide la canti¬ 
dad de unidades vendidas. Algunos de los demás atri¬ 
butos (o todos ellos) de la relación se identifican como 
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atributos de dimensión, ya que definen las dimensio¬ 
nes en las que se ven los atributos de medida y los resú¬ 
menes de los atributos de medida. En la relación ventas, 
nombre-artículo, color y talla son atributos de dimen¬ 
sión. (Una versión más realista de la relación ventas ten¬ 
dría más dimensiones, como tiempo o lugar de venta, y 
más medidas como el valor monetario de la venta.) 

Los datos que pueden modelarse como atributos de 
dimensión y como atributos de medida se denominan 
datos multidimensionales. 

Para analizar los datos multidimensionales puede que 
el administrador desee ver los datos dispuestos como se 
ven en la tabla de la Figura 22.1. La tabla muestra las 
cifras totales de diferentes combinaciones de nombre- 
artículo y color. El valor de talla se especifica como 
todas, lo que indica que los valores mostrados son un 
resumen para todos los valores de talla. 

La tabla de la Figura 22.1 es un ejemplo de tabula¬ 
ción cruzada, también denominada tabla dinámica. 
En general, las tabulaciones cruzadas son tablas en las 
que los valores de uno de los atributos (por ejemplo, A ) 
forman las cabeceras de las filas, los valores del otro 
atributo (por ejemplo, B) forman las cabeceras de las 
columnas y los valores de cada celda se obtienen como 
sigue: cada celda puede identificarse como ( a¡, b¡), don¬ 
de a¡ es un valor de A y l> ¡ un valor de B. Si hay como 
máximo una tupia con cualquier valor de (a,, bj), el valor 
de la celda se obtiene de esa única tupia (si es que hay 
alguna); por ejemplo, puede ser el valor de uno o varios 
atributos de la tupia. Si puede haber varias tupias con 
el valor ( a¡, bj), el valor de la celda debe obtenerse por 
agregación de las tupias con ese valor. En este ejemplo 
la agregación utilizada es la suma de los valores del atri¬ 
buto número. En este ejemplo la tabulación cruzada tam¬ 
bién tiene una columna y una fila adicionales que guar¬ 
dan los totales de las celdas de cada fila o columna. La 
mayor parte de las tabulaciones cruzadas tienen esas 
filas y columnas de resumen. 

Las tabulaciones cruzadas son diferentes de las tablas 
relaciónales que suelen guardarse en las bases de datos, 
ya que el número de columnas de la tabulación cruza¬ 
da depende de los datos. Una modificación en los valo¬ 
res de los datos puede dar lugar a que se añadan más 
columnas, lo que no resulta deseable para el almacena¬ 
miento de los datos. No obstante, la vista de tabulación 


nombre-artículo 

color 

número 

falda 

oscuro 

8 

falda 

pastel 

35 

falda 

blanco 

10 

falda 

all 

53 

vestido 

oscuro 

20 

vestido 

pastel 

10 

vestido 

blanco 

5 

vestido 

all 

35 

camisa 

oscuro 

14 

camisa 

pastel 

7 

camisa 

blanco 

28 

camisa 

all 

49 

pantalones 

oscuro 

20 

pantalones 

pastel 

2 

pantalones 

blanco 

5 

pantalones 

all 

27 

all 

oscuro 

62 

all 

pastel 

54 

all 

blanco 

48 

all 

all 

164 


FIGURA 22.2. Representación relacional de los datos de la 
Figura 22.1. 


cruzada es deseable para mostrársela a los usuarios. La 
representación de las tabulaciones cruzadas sin valores 
resumen en un formulario relacional con un número fijo 
de columnas es directa. La tabulación cruzada con 
columnas o filas resumen puede representarse introdu¬ 
ciendo el valor especial all (todos) para representar los 
subtotales, como en la Figura 22.2. La norma SQL: 1999 
utiliza realmente el valor nuil (nulo) en lugar de all; 
pero, para evitar confusiones con los valores nulos habi¬ 
tuales, en el libro se seguirá utilizando all. 

Considérense las tupias (falda, all, 53) y (vestido, 
all, 35). Se han obtenido estas tupias eliminando las 
tupias individuales con diferentes valores de color y 
sustituyendo el valor de número por un agregado, es 
decir, una suma. El valor all puede considerarse repre¬ 
sentante del conjunto de los valores de un atributo. Las 
tupias con el valor all sólo para la dimensión color pue¬ 
den obtenerse mediante una consulta de SQL que lleve 
a cabo una agrupación en la columna nombre-artículo. 
De manera parecida, se puede utilizar una agrupación 
en color para conseguir las tupias con el valor all para 


talla: 


all 


nombre-artículo 


color 



oscuro 

pastel 

blanco 

Total 

falda 

8 

35 

10 

53 

vestido 

20 

10 

5 

35 

camisa 

14 

7 

28 

49 

pantalón 

20 

2 

5 

27 

Total 

62 

54 

48 

164 


FIGURA 22.1. Tabulación cruzada de ventas con nombre-artículo y color. 
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FIGURA 22.3. Cubo de datos tridimensional. 


nombre-artículo, y una agrupación sin atributo alguno 
(que en SQL puede omitirse simplemente) puede utili¬ 
zarse para obtener la tupia con el valor all para nombre- 
artículo y color. 

La generalización de las tabulaciones cruzadas, que 
son bidimensionales, a n dimensiones puede visuali¬ 
zarse como cubos n dimensionales, denominados cubos 
de datos. La Figura 22.3 muestra un cubo de datos para 
la relación ventas. El cubo de datos tiene tres dimen¬ 
siones, a saber, nombre-artículo, color y talla, y el atri¬ 
buto de medida es número. Cada celda se identifica por 
los valores de estas tres dimensiones. Cada celda del 
cubo de datos contiene un valor, igual que en la tabula¬ 
ción cruzada. En la Figura 22.3, el valor contenido en 
la celda se muestra en una de las caras de la celda; las 
otras caras de la celda se muestran en blanco si son visi¬ 
bles. 

El valor de una dimensión puede ser all, en cuyo caso 
la celda contiene un resumen de todos los valores de esa 
dimensión, como en el caso de las tabulaciones cruza¬ 
das. El número de maneras diferentes en que las tupias 
pueden agruparse para su agregación puede ser grande. 
De hecho, para una tabla con n dimensiones, se puede 
realizar la agregación con la agrupación de cada uno de 
los 2" subconjuntos de las n dimensiones 1 . 

El sistema de procesamiento analítico en línea o sis¬ 
tema OLAP es un sistema interactivo que permite a los 
analistas ver diferentes resúmenes de los datos multi- 
dimensionales. Las palabras en línea indican que los 
analistas deben poder solicitar nuevos resúmenes y obte¬ 


' La agrupación sobre el conjunto de las n dimensiones sólo resulta 
útil si la tabla puede tener duplicados. 


ner respuestas en línea, en pocos segundos, y no debe¬ 
rían verse obligados a esperar mucho tiempo para ver 
el resultado de las consultas. 

Con los sistemas OLAP los analistas de datos pue¬ 
den ver diferentes tabulaciones cruzadas para los mis¬ 
mos datos seleccionando de manera interactiva los atri¬ 
butos de las tabulaciones cruzadas. Cada tabulación 
cruzada es una vista bidimensional del cubo de datos 
multidimensional. Por ejemplo, el analista puede selec¬ 
cionar una tabulación cruzada para nombre-artículo y 
talla o una tabulación cruzada para color y talla. La ope¬ 
ración de modificación de las dimensiones utilizadas en 
las tabulaciones cruzadas se denomina pivotaje. 

Los sistemas OLAP también ofrecen otras funcio¬ 
nalidades. Por ejemplo, puede que un analista desee ver 
una tabulación cruzada de nombre-artículo y color para 
un valor fijo de talla, por ejemplo, grande, en lugar de 
la suma para todas las tallas. Esta operación se conoce 
como corte, ya que puede considerarse como la vista 
de una rebanada del cubo de datos. A veces la opera¬ 
ción se denomina corte de cubos, especialmente cuan¬ 
do se fijan los valores de varias dimensiones. 

Cuando se utilizan tabulaciones cruzadas para ver 
cubos multidimensionales los valores de los atributos 
de dimensión que no forman parte de la tabulación cru¬ 
zada se muestran por encima de ella. El valor de estos 
atributos puede ser all, como puede verse en la Figura 
22.1, lo que indica que los datos de la tabulación cru¬ 
zada son un resumen de todos los valores del atributo. 
El corte y la creación de datos consisten simplemente 
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en la selección de valores concretos de estos atributos, 
que se muestran luego por encima de la tabulación cru¬ 
zada. 

Los sistemas OLAP permiten a los usuarios ver los 
datos con cualquier nivel de granularidad que se desee. 
La operación de pasar de datos con una granularidad 
más fina a una granularidad más gruesa (mediante la 
agregación) se denomina abstracción. En este ejemplo, 
a partir del cubo de datos para la tabla ventas, se obtie¬ 
ne la tabulación cruzada de ejemplo abstrayendo el atri¬ 
buto talla. La operación inversa —la de pasar de datos 
con una granularidad más gruesa a una más fina— se 
denomina concreción. Claramente, los datos con gra¬ 
nularidad más fina no pueden generarse a partir de datos 
con una granularidad más gruesa; deben generarse a 
partir de los datos originales o de datos resumidos de 
granularidad aún más fina. 

Puede que un analista desee ver una dimensión con 
niveles diferentes de detalle. Por ejemplo, los atributos 
de tipo FechaHora contienen una fecha y una hora del 
día. El empleo de horas con precisión de segundos (o 
menos) puede que no sea significativo: los analistas que 
estén interesados en la hora aproximada del día puede 
que sólo miren el valor horario. Los analistas que estén 
interesados en las ventas de cada día de la semana pue¬ 
de que apliquen la fecha al día de la semana y sólo se 
fijen en eso. Puede que otro analista esté interesado en 
agregados mensuales, trimestrales o de años enteros. 

Los diferentes niveles de detalle de los atributos pue¬ 
den organizarse en una jerarquía. La Figura 22.4(a) 
muestra una jerarquía para el atributo FechaHora. La 
Figura 22.4(b), que puede ser otro ejemplo, muestra una 
jerarquía para la ubicación, con la ciudad en la parte infe¬ 
rior de la jerarquía, el estado por encima, el país en el 
nivel siguiente y la región en el nivel superior. En el ejem¬ 
plo anterior la ropa puede agruparse por categorías (por 
ejemplo, ropa de hombre o de mujer); la categoría esta- 


Año 


Trimestre 


Día de la semana Mes 



Hora del día Fecha 



FechaHora 


Región 


País 


Estado 


Ciudad 


a) Jerarquía de tiempo b) Jerarquía de ubicación 

FIGURA 22.4. Jerarquías de las dimensiones. 


ría por encima de nombre-artículo en la jerarquía de la 
ropa. En el nivel de los valores reales las faldas y los ves¬ 
tidos caerían dentro de la categoría de ropa de mujer y 
los pantalones y las camisas en la de ropa de hombre. 

Puede que un analista esté interesado en ver las ven¬ 
tas de ropa divididas entre ropa de hombre y ropa de 
mujer y que no esté interesado en ver los valores indi¬ 
viduales. Tras ver los agregados en el nivel de ropa de 
hombre y ropa de mujer puede que el analista concrete 
la jerarquía para ver los valores individuales. Un ana¬ 
lista que examine el nivel detallado puede abstraer la 
jerarquía y examinar agregados de niveles más grue¬ 
sos. Ambos niveles pueden mostrarse en la misma tabu¬ 
lación cruzada, como en la Figura 22.5. 

22.2.2. Implementación de OLAP 

Los primeros sistemas de OLAP utilizaban arrays de 
memoria multidimensionales para almacenar los cubos 
de datos y se denominaban sistemas OLAP multidi¬ 
mensionales (Multidimensional OLAP, MOLAP). 
Posteriormente, los servicios OLAP se integraron en los 
sistemas relaciónales y los datos se almacenaron en las 
bases de datos relaciónales. Estos sistemas se denomi¬ 
nan sistemas OLAP relaciónales (Relational OLAP, 
ROLAP). Los sistemas híbridos, que almacenan algu¬ 
nos resúmenes en la memoria y los datos básicos y otros 
resúmenes en bases de datos relaciónales, se denominan 
sistemas OLAP híbridos (Hybrid OLAP, HOLAP). 

Muchos sistemas OLAP se implementan como sis¬ 
temas cliente-servidor. El servidor contiene la base de 
datos relacional y los cubos de datos MOLAP. Los sis¬ 
temas clientes obtienen vistas de los datos comunicán¬ 
dose con el servidor. 

Una manera ingenua de calcular todo el cubo de datos 
(todas las agmpaciones) de una relación es utilizar cual¬ 
quier algoritmo estándar para calcular las operaciones 
de agregación, agrupación a agrupación. El algoritmo 
ingenuo necesita un gran número de exploraciones de 
la relación. Una optimización sencilla consiste en calcu¬ 
lar el agregado para, por ejemplo ( nombre-artículo, 
color ) a partir del agregado ( nombre-artículo, color, 
talla), en lugar de hacerlo a partir de la relación origi¬ 
nal. Para las funciones de agregación estándar de SQL 
se pueden calcular agregados con agrupaciones sobre 
un conjunto de atributos A a partir de un agregado con 
agmpación sobre un conjunto de atributos BÚA c B: 
se puede hacer como ejercicio (véase el Ejercicio 22.1), 
pero hay que tener en cuenta que al calcular avg tam¬ 
bién hace falta el valor count. (Para algunas funciones 
de agregación no estándar como la mediana, los agre¬ 
gados no pueden calcularse de la manera indicada; la 
optimización aquí descrita no es aplicable a estas fun¬ 
ciones de agregación «no-descomponibles».) La canti¬ 
dad de datos que se lee disminuye de manera significa¬ 
tiva al calcular los agregados a partir de otros agregados, 
en lugar de hacerlo a partir de la relación original. Se 
pueden conseguir otras mejoras; por ejemplo, se pue- 
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categoría nombre-artículo 




oscura 

pastel 

blanca 

total 

ropa de hombre 

camisa 

8 

8 

10 

53 



pantalones 

20 

20 

5 

35 



subtotal 

28 

28 

15 


88 

ropa de mujer 

falda 

14 

14 

28 

49 



vestido 

20 

20 

5 

27 



subtotal 

34 

34 

33 


76 

total 


62 

62 

48 


164 


FIGURA 22.5. Tabulación cruzada de ventas con la jerarquía para nombre-artículo. 


den calcular varias agrupaciones con una sola lectura 
de los datos. Véanse las notas bibliográficas para hallar 
referencias a los algoritmos para el cálculo eficiente de 
cubos de datos. 

Las primeras implementaciones OLAP calculaban 
previamente los cubos de datos completos, es decir, las 
agrupaciones por todos los subconjuntos de los atribu¬ 
tos de dimensión, y los almacenaban. El cálculo previo 
permite que las consultas OLAP se respondan en pocos 
segundos, incluso para conjuntos de datos que pueden 
contener millones de tupias que suponen gigabytes de 
datos. No obstante, hay 2" agrupaciones con n atribu¬ 
tos de dimensión; las jerarquías de los atributos aumen¬ 
tan más aún el número. En consecuencia, todo el cubo 
de datos suele ser mayor que la relación original que lo 
generó y, en muchos casos, no resulta posible almace¬ 
narlo entero. 

En lugar de calcular previamente todas las agrupa¬ 
ciones posibles y almacenarlas, resulta razonable calcu¬ 
lar previamente algunas de las agrupaciones y almace¬ 
narlas y calcular el resto según se soliciten. En lugar de 
calcular las consultas a partir de la relación original, lo 
que puede tardar mucho tiempo, se pueden calcular a 
partir de otras consultas calculadas previamente. Por 
ejemplo, supóngase que una consulta necesita resúme¬ 
nes según ( nombre-artículo, color), que no se ha 
calculado con anterioridad. El resultado de la consulta 
puede calcularse a partir de resúmenes según ( nombre- 
artículo, color, talla), si ya se ha calculado. Véanse las 
notas bibliográficas para hallar referencias al modo de 
seleccionar para su cálculo previo un buen conjunto de 
agrupaciones, dados los límites de almacenamiento dis¬ 
ponible para los resultados calculados previamente. 

Los datos de los cubos no se pueden generar median¬ 
te una sola consulta SQL utilizando las estmcturas bási¬ 
cas group by, ya que los agregados se calculan para 
varias agrupaciones diferentes de los atributos de dimen¬ 
sión. El Apartado 22.2.3 estudia las extensiones de SQL 
para el soporte de la funcionalidad OLAP. 


22.2.3. Ampliación de la agregación 

La funcionalidad de agregación de SQL-92 está limita¬ 
da, por lo que diferentes bases de datos han implemen- 
tado varias extensiones. No obstante, la norma 
SQL: 1999 define un amplio conjunto de funciones de 
agregación, que se describen en este apartado y en los 
dos siguientes. Las bases de datos de Oracle y de DB2 
de IBM soportan la mayor parte de estas características 
y, sin duda, otras bases de datos soportarán estas carac¬ 
terísticas en un futuro próximo. 

Las nuevas funciones de agregación para un solo atri¬ 
buto son la desviación estándar y la varianza (stddev y 
variance). La desviación estándar es la raíz cuadrada 
de la varianza 2 . Algunos sistemas de bases de datos 
soportan otras funciones de agregación como la media¬ 
na y la moda. Algunos sistemas de bases de datos inclu¬ 
so permiten que los usuarios añadan nuevas funciones 
de agregación. 

SQL: 1999 también soporta una nueva clase de fun¬ 
ciones de agregación binarias, que pueden calcular 
resultados estadísticos para parejas de atributos; entre 
ellas están las correlaciones, las covarianzas y las cur¬ 
vas de regresión, que dan una línea que aproxima la rela¬ 
ción entre los valores de la pareja de atributos. Las defi¬ 
niciones de estas funciones pueden hallarse en cualquier 
libro de texto estándar, como los que se citan en las notas 
bibliográficas. 

SQL: 1999 también soporta generalizaciones de la 
estructura group by, mediante las estructuras cube y 
rollup. Un uso representativo de la estructura cube es 
el siguiente: 

select nombre-artículo, color, talla, sum {número) 

from ventas 

group by cub ^{nombre-artículo, color, talla) 

Esta consulta calcula la unión de ocho agrupaciones 
diferentes de la relación ventas : 


2 La norma SQL: 1999 soporta en realidad dos tipos de varianza, deno¬ 
minadas varianza de la población y varianza de la muestra y, por 
tanto, dos tipos de desviación estándar. La definición de los dos tipos 
difiere ligeramente; los detalles se pueden consultar en cualquier libro 
de texto de estadística. 
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) {nombre-artículo, color, talla), {nombre-artículo, 
color), {nombre-artículo, talla), {color, talla), 
{nombre-artículo), {color), {talla), () } 

donde () denota una lista group by vacía. 

Para cada agrupación el resultado contiene el valor 
nulo para los atributos no presentes en la agrupación. 
Por ejemplo, la tabla de la Figura 22.2, sustituyendo all 
por nuil, la puede calcular la consulta 

select nombre-artículo, color, sum {número) 
from ventas 

group by cub ^{nombre-artículo, color) 

Una estructura rollup representativa es 

selectC nombre-artículo, color, talla, sum {número) 
from ventas 

group by rollup {nombre-artículo, color, talla) 

En este caso sólo se han generado cuatro agrupaciones: 

{ {nombre-artículo, color, talla), {nombre-artículo, 
color), {nombre-artículo), {) ) 

La instrucción rollup puede utilizarse para generar 
agregados en varios niveles de una jerarquía para una 
columna. Por ejemplo, supóngase que se tiene la tabla 
categoríaartículo{nombre-artículo, categoría) que da 
la categoría de cada artículo. La consulta 

select categoría, nombre-artículo, sum {número) 
from ventas, categoríaartículo 
where ventas.nombre-artículo 

= categoríaartículo.nombre-artículo 
group by rollup {categoría, nombre-artículo) 

da un resumen jerárquico según nombre-artículo y según 
categoría. 

Se pueden utilizar varios rollup y varios cube en 
una sola cláusula group by. Por ejemplo, la consulta 
siguiente 

select nombre-artículo, color, talla, sum {número) 
from ventas 

group by rollup {nombre-artículo), rol lupico /o/, talla) 
genera las agrupaciones 


Como ya se ha mencionado en el Apartado 22.2.1, 
SQL: 1999 utiliza el valor nuil para indicar el sentido 
habitual de nulo así como all. Este uso dual de nuil pue¬ 
de generar ambigüedad si los atributos utilizados en una 
cláusula rollup o en una cláusula cube contienen valo¬ 
res nulos. Se puede aplicar la función grouping a un 
atributo; devuelve 1 si el valor es un valor nulo que 
represente a all, y devuelve 0 en los demás casos. Con¬ 
sidérese la consulta siguiente: 

select nombre-artículo, color, talla, sum {número), 
grouping {nombre-artículo) 

as indicador-nombre-artículo, 
grouping {color) as indicador-color, 
grouping {talla) as indicador-talla 
from ventas 

group by cube{nombre-artículo, color, talla) 

El resultado es el mismo que en la versión de la con¬ 
sulta sin grouping, pero con tres columnas adicionales 
denominadas indicador-nombre-artículo, indicador- 
color y indicador-talla. En cada tupia el valor de los 
campos indicador es 1 si el campo correspondiente es 
un valor nulo que respresente a all. 

En lugar de utilizar etiquetas para indicar los valo¬ 
res nulos que representan a all, se pueden sustituir los 
valores nulos por un valor a la elección del usuario: 

decode(grouping {nombre-artículo), 1, ‘todos’, 
nombre-artículo) 

Esta expresión devuelve el valor «todos» si el valor de 
nombre-artículo es un valor nulo que se corresponda 
con all, y devuelve el valor real de nombre-artículo en 
caso contrario. Esta expresión puede utilizarse en lugar 
de nombre-artículo en la cláusula select para obtener 
«todos» en el resultado de la consulta, en lugar de valo¬ 
res nulos que representen a all. 

Ni la cláusula rollup ni la cláusula cube ofrecen un 
control completo de las agrupaciones que se generan. 
Por ejemplo, no se pueden utilizar para especificar que 
sólo se desean las agrupaciones | {color, talla), {talla, 
nombre-artículo)}. Estas agrupaciones restringidas pue¬ 
den generarse utilizando la estructura grouping en la 
cláusula having; los detalles se dejan como ejercicio 
para el lector. 

22.2.4. Clasificación 


{ {nombre-artículo, color, talla), {nombre-artículo. Hallar la posición de un valor en un conjunto más gran- 

color), {nombre-artículo), {color, talla), {color), () ( de es una operación frecuente. Por ejemplo, puede que 

se desee asignar una clasificación a los estudiantes de 
Para comprender el motivo hay que tener en cuenta que acuerdo con sus notas totales, con el puesto 1 para el 

rollup {nombre-artículo) genera dos agrupaciones, estudiante con las notas más altas, el puesto 2 para el 

{( nombreartículo ), ()}, y que rollup(co/o/; talla) gene- estudiante con las segundas mejores notas, etcétera, 
ra tres agmpaciones, j {color, talla), {color), {) (.El pro- Aunque estas consultas pueden expresarse en SQL-92, 

ducto cartesiano de los dos da como resultado las seis resultan difíciles de expresar e ineficientes a la hora de 

agmpaciones mostradas. la evaluación. Los programadores suelen recurrir a escri- 
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bir en parte la consulta en SQL y en parte en un len¬ 
guaje de programación. Un tipo de consulta relaciona¬ 
do es la búsqueda del percentil que le corresponde a un 
valor de un (multi)conjunto, por ejemplo, el tercio infe¬ 
rior, el tercio central o el tercio superior. Aquí se estu¬ 
diará el soporte de SQL: 1999 para estos tipos de con¬ 
sultas. 

La clasificación se realiza conjuntamente con una 
especificación order by. Supóngase que se tiene una 
relación estudiante-notasiid-estudiante, notas) que alma¬ 
cena las notas obtenidas por cada estudiante. La con¬ 
sulta siguiente da la clasificación de cada estudiante. 

select id-estudiante, rank() over (order by {notas) 
dése) as clasificación-e 

from notas-estudiante 

Obsérvese que el orden de las tupias en el resultado no 
se ha definido, por lo que puede que no estén ordena¬ 
das según su clasificación. Se necesita una cláusula 
order by adicional para dejarlas ordenadas, como pue¬ 
de verse a continuación. 

select id-estudiante, rank () over (order by {notas) 
dése) as clasificación-e 

from notas-estudiante order by clasificación-e 

Un aspecto básico de las clasificaciones es el modo 
de tratar el caso de que haya varias tupias que sean igua¬ 
les en el atributo o atributos de ordenación. En el ejem¬ 
plo anterior esto significa decidir lo que se hace si hay 
dos estudiantes con la mismas notas. La función rank 
da la misma clasificación a todas las tupias que sean 
iguales en los atributos order by. Por ejemplo, si la nota 
más elevada la comparten dos estudiantes, los dos obten¬ 
drían el puesto 1. El puesto siguiente que se diera sería 
el 3, no el 2, por lo que si tres estudiantes consiguieran 
la siguiente nota más alta, todos ellos obtendrían el pues¬ 
to 3, y los siguientes estudiantes obtendrían el pues¬ 
to 5, etcétera. También hay una función dense rank que 
no crea saltos en la ordenación. En el ejemplo anterior 
las tupias con el segundo valor más alto obtienen el 
puesto 2 y las tupias con el tercer valor más elevado 
obtienen el puesto 3, etcétera. 

Se puede llevar a cabo la clasificación dentro de par¬ 
ticiones de los datos. Por ejemplo, supóngase que se tie¬ 
ne una relación adicional estudiante-sección{id-estu- 
diante, sección) que almacena para cada estudiante la 
sección en la que estudia. La consulta siguiente da la 
clasificación de los estudiantes dentro de cada sección. 

select id-estudiante, sección, 

rank () over (partition by sección 
order by notas dése) as clasificación-sec 


from notas-estudiante, sección-estudiante 
where notas-estudiante.id-estudiante 

= sección-estudiante.id-estudiante 
order by sección, clasificación-sec 

La cláusula order by extema ordena las tupias del resul¬ 
tado por secciones y, dentro de cada sección, por su cla¬ 
sificación. 

Se pueden utilizar varias expresiones rank dentro de 
cada sentencia select; por tanto, se puede obtener la cla¬ 
sificación general y la clasificación dentro de cada sec¬ 
ción empleando dos expresiones rank en la misma cláu¬ 
sula select. Una pregunta interesante es lo que ocurre 
cuando se produce una clasificación (posiblemente con 
partición) junto con una cláusula group by. En ese caso, 
la cláusula group by se aplica en primer lugar y la parti¬ 
ción y la clasificación se realizan sobre los resultados de 
la cláusula group by. Así, los valores agregados pueden 
utilizarse para la clasificación. Por ejemplo, supóngase 
que se tienen las notas de cada estudiante en varias asig¬ 
naturas. Para clasificar a los estudiantes por la suma de 
sus notas en varias asignaturas se puede utilizar una cláu¬ 
sula group by para calcular las notas agregadas de cada 
estudiante y luego clasificar a los estudiantes por la suma 
agregada. Los detalles se le dejan al lector como ejercicio. 

Las funciones de clasificación pueden utilizarse para 
hallar las n primeras tupias incrustando una consulta de 
clasificación en una consulta de un nivel exterior; los 
detalles se dejan para un ejercicio. Téngase en cuenta 
que las n últimas tupias son simplemente las mismas 
que las n primeras con un orden inverso. Varios siste¬ 
mas de bases de datos ofrecen extensiones no estándar 
de SQL para especificar directamente que sólo se nece¬ 
sitan los n primeros resultados; esas extensiones no nece¬ 
sitan la función de clasificación y simplifican el traba¬ 
jo del optimizador, pero (actualmente) no son tan 
generales, ya que no soportan las particiones. 

SQL: 1999 también especifica otras funciones que 
pueden utilizarse en lugar de rank. Por ejemplo, per- 
cent rank de una tupia da la clasificación de la tupia en 
forma de fracción. Si hay n tupias en la partición y la 
clasificación de la tupia es r, su clasificación percentual 
se define como {r - 1)/(/? - 1) (y como nula si sólo hay 
una tupia en la partición). La función cume_dist, abre¬ 
viatura de distribución acumulativa (cumulative distri- 
bution), para una tupia se define como pin, donde p es 
el número de tupias de la partición con valores de orde¬ 
nación que preceden o son iguales al valor de ordena¬ 
ción de la tupia, y n es el número de tupias de la parti¬ 
ción. La función row number ordena las filas y da a 
cada una un número único correspondiente a su posi¬ 
ción en el orden; filas diferentes con el mismo valor de 
ordenación reciben números de fila diferentes, de mane¬ 
ra no determinista. 


3 Todo el conjunto se trata como una sola partición si no se utiliza 
ninguna partición explícita. 


544 



CAPÍTUIO 22 CONSULTAS AVANZADAS Y RECUPERACIÓN DE LA INFORMACIÓN 


Finalmente, para una constante dada n, la función de 
clasificación ntile(n) toma las tupias de cada partición 
en el orden especificado y las divide en n cajones con 
igual número de tupias 4 . Para cada tupia, ntile(n) da el 
número del cajón en el que se halla, con los números de 
los cajones comenzando por 1. Esta función resulta espe¬ 
cialmente útil para la creación de histogramas basados 
en percentiles. Por ejemplo, se pueden ordenar los 
empleados por su salario y utilizar nt¡le(3) para hallar 
el rango (tercio inferior, tercio central o tercio superior) 
en el que se halla cada empleado, y para calcular el sala¬ 
rio total ganado por los empleados de cada rango: 

select tercil, sum (sueldo) 

from ( 

select sueldo, ntile(3) over (order by {sueldo)) 
as tercil 

from empleado) as s 
group by tercil. 

La presencia de valores nulos puede complicar la 
definición de la clasificación, dado que no está claro si 
deben colocarse antes en el orden. SQL: 1999 permite 
que el usuario especifique dónde deben aparecer median¬ 
te nulls first o nulls last, por ejemplo 

select id-estudiante, rank () over (order by notas 
dése nulls last) as clasificación-e 
from notas-estudiante 

22.2.5. Ventanas 

Un ejemplo de consulta ventana es una consulta que, 
dados los valores de ventas para cada fecha, calcula para 
cada fecha el promedio de ventas de ese día, del día 
anterior y del día siguiente; esas consultas de media 
móvil se utilizan para suavizar las variaciones aleato¬ 
rias. Otro ejemplo de consulta ventana es la consulta 
que halla el saldo acumulado de una cuenta, dada una 
relación que especifique las imposiciones y las retira¬ 
das de fondos de la cuenta. Esas consultas resultan difí¬ 
ciles o imposibles de expresar (depende de la consulta 
en concreto) en SQL básico. 

SQL: 1999 ofrece una característica de ventanas para 
soportar esas consultas. A diferencia de group by, la 
misma tupia puede estar en varias ventanas. Supónga¬ 
se que se tiene la relación transacción(número-cuenta, 
fecha-hora, valor), donde valor es positivo para las 
imposiciones de fondos y negativo para las retiradas. 
Se da por supuesto que hay como máximo una transac¬ 
ción por cada valor fecha-hora. 

Considérese la consulta 


select número-cuenta, fecha-hora, 
sum(vfl/o/-) over 

(partition by número-cuenta 
order by fecha-hora 

rows unbounded preceding) 

as saldo 

from transacción 

order by número-cuenta, fecha-hora 

La consulta da los saldos acumulados de cada cuenta 
justo antes de cada transacción en esa cuenta; el saldo 
acumulado de una cuenta es la suma de valores de todas 
las transacciones anteriores de la cuenta. 

La cláusula partition by separa las tupias por núme¬ 
ro de cuenta, de modo que para cada fila sólo se consi¬ 
deren las tupias de su partición. Se crea una ventana para 
cada tupia; las palabras clave rows unbounded prece¬ 
ding especifican que la ventana de cada tupia consiste en 
todas las tupias de la partición que la preceden en el orden 
especificado (en este caso, orden creciente d e fecha-hora). 
La función de agregación sum( va/or) se aplica a todas 
las tupias de la ventana. Obsérvese que la consulta no uti¬ 
liza ninguna cláusula group by, ya que hay una tupia de 
resultado por cada tupia de la relación transacción. 

Aunque la consulta puede escribirse sin las estruc¬ 
turas ampliadas, sería bastante difícil de formular. Obsér¬ 
vese también que se pueden superponer diferentes ven¬ 
tanas, es decir, una tupia puede estar presente en más 
de una ventana. 

Se pueden especificar otros tipos de ventanas. Por 
ejemplo, para obtener una ventana que contenga las 10 
filas anteriores a cada fila, se puede especificar rows 
10 preceding. Para obtener una ventana que contenga 
la fila actual, la anterior y la siguiente se puede utilizar 
between rows 1 preceding and 1 following. Para obte¬ 
ner las filas siguientes y la fila actual se puede decir bet¬ 
ween rows unbounded preceding and current. Obsér¬ 
vese que si la ordenación se realiza sobre un atributo 
que no sea clave el resultado no es determinista, ya que 
el orden de las tupias no está definido completamente. 

Se pueden especificar ventanas mediante rangos de 
valores, en lugar de hacerlo mediante número de filas. Por 
ejemplo, supóngase que el valor de ordenación de una 
tupia es v; entonces, range between 10 preceding and 
current row dará tupias cuyo valor de ordenación se halle 
entre v - 10 y v (ambos valores incluidos). Al tratar con 
fechas se puede utilizar range interval 10 day preceding 
para obtener una ventana que contenga tupias con los 10 
días anteriores, pero sin incluir la fecha de la tupia. 

Evidentemente, la funcionalidad de ventanas de 
SQL: 1999 es mucho más rica y puede utilizarse para 
escribir consultas bastante complejas con poco esfuerzo. 


4 Si el número total de tupias de una partición no es divisible por n, 
el número de tupias de cada cajón puede variar como mucho en 1. 
Las tupias con el mismo valor del atributo de ordenación pueden 
asignarse cajones diferentes, de manera no determinista, para hacer 
igual el número de tupias de cada cajón. 
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22.3. RECOPILACIÓN DE DATOS 


El término recopilación de datos (data mining) hace 
referencia vagamente al proceso de análisis semiauto- 
mático de bases de datos de gran tamaño para hallar 
estructuras útiles. Al igual que la búsqueda de conoci¬ 
miento en la inteligencia artificial (también denomina¬ 
da aprendizaje de la máquina), o el análisis estadístico, 
la recopilación de datos intenta descubrir reglas y estruc¬ 
turas a partir de los datos. No obstante, la recopilación 
de datos se diferencia del aprendizaje de la máquina y 
de la estadística en que trata con grandes volúmenes de 
datos, almacenados sobre todo en disco. Es decir, la 
recopilación de datos trata de la «búsqueda de conoci¬ 
miento en las bases de datos». 

Algunos tipos de conocimiento descubiertos a par¬ 
tir de una base de datos pueden representarse por un 
conjunto de reglas. A continuación se ofrece un ejem¬ 
plo de regla, formulada de manera informal: «Las muje¬ 
res jóvenes con ingresos anuales superiores a 50.000 € 
son las personas que con mayor probabilidad compran 
coches deportivos de pequeño tamaño». Por supuesto, 
estas reglas no son verdaderas de modo universal, y tie¬ 
nen grados de «soporte» y de «confianza», como se verá. 
Otros tipos de conocimiento se representan por ecua¬ 
ciones que relacionan entre sí diferentes variables, o 
mediante otros mecanismos de predicción de resulta¬ 
dos cuando se conocen los valores de algunas variables. 

Hay gran variedad de tipos posibles de estructuras 
que pueden resultar útiles, y se emplean diferentes téc¬ 
nicas para hallar tipos diferentes de estructuras. Se estu¬ 
diarán unos cuantos ejemplos de estructuras y se verá 
el modo en que pueden obtenerse de manera automáti¬ 
ca de las bases de datos. 

Suele haber una parte manual en la recopilación de 
datos, que consiste en el preprocesamiento de los datos 
hasta una forma aceptable para los algoritmos, y en el 
posprocesamiento de las estructuras descubiertas para 
hallar otras nuevas que puedan resultar útiles. También 
puede haber más de un tipo de estructura que se pueda 
descubrir a partir de una base de datos dada, y puede 
que se necesite la interacción manual para escoger los 
tipos de estructuras útiles. Por este motivo, la recopila¬ 
ción de datos es realmente un proceso semiautomático 
en la vida real. No obstante, la descripción que sigue se 
centrará en el aspecto automático de la recopilación. 

22.3.1. Aplicaciones de la recopilación 
de datos 

La información hallada tiene numerosas aplicaciones. 
Las aplicaciones más utilizadas son las que necesitan 
algún tipo de predicción. Por ejemplo, cuando una per¬ 
sona solicita una tarjeta de crédito, la compañía emiso¬ 
ra quiere predecir si la persona constituye un buen ries¬ 
go de crédito. La predicción tiene que basarse en los 
atributos conocidos de la persona, como la edad, sus 


ingresos, sus deudas y su historial de pago de deudas. 
Las reglas para realizar la predicción se deducen de los 
mismos atributos de titulares de tarjetas de crédito pasa¬ 
dos y actuales, junto con su conducta observada, como 
puede ser si han dejado de pagar los cargos de su tarje¬ 
ta de crédito. Entre otros tipos de predicción están la 
predicción de los consumidores que pueden pasarse a 
un competidor (puede que se ofrezca a esos consumi¬ 
dores descuentos especiales para intentar que no se cam¬ 
bien), la predicción de la gente que puede responder a 
correo publicitario («correo basura») o la predicción de 
los tipos de empleo de tarjetas telefónicas que pueden 
resultar fraudulentos. 

Otra clase de aplicaciones busca asociaciones, por 
ejemplo, los libros que se suelen comprar juntos. Si un 
cliente compra un libro, puede que la librería en línea 
le sugiera otros libros asociados. Si una persona com¬ 
pra una cámara, puede que el sistema sugiera acceso¬ 
rios que suelen comprarse junto a las cámaras. Un buen 
vendedor está atento a esas tendencias y las aprovecha 
para realizar más ventas. El desafío consiste en auto¬ 
matizar el proceso. Puede que otros tipos de asociación 
lleven al descubrimiento de relaciones causa-efecto. Por 
ejemplo, el descubrimiento de asociaciones inespera¬ 
das entre un medicamento recién introducido y los pro¬ 
blemas cardiacos llevó al hallazgo de que el medica¬ 
mento puede causar problemas cardiacos en algunas 
personas. El medicamento se retiró del mercado. 

Las asociaciones son un ejemplo de patrones des¬ 
criptivos. Las agrupaciones son otro ejemplo de este 
tipo de patrones. Por ejemplo, hace más de un siglo se 
descubrió una agrupación de casos de fiebre tifoidea 
alrededor de un pozo, lo que llevó al descubrimiento de 
que el agua del pozo estaba contaminada y estaba difun¬ 
diendo la fiebre tifoidea. La detección de agrupaciones 
de enfermedades sigue siendo importante hoy en día. 

22.3.2. Clasificación 

Como ya se mencionó en el Apartado 22.3.1, la pre¬ 
dicción es uno de los tipos más importantes de recopi¬ 
lación de datos. Se describirá lo que es la clasificación, 
se estudiarán técnicas para la creación de un tipo de cla¬ 
sificadores, denominados clasificadores de árboles de 
decisión, y se estudiarán otras técnicas de predicción. 

De manera abstracta, el problema de la clasificación 
es el siguiente: dado que los elementos pertenecen a una 
de las clases, y dados los casos pasados (denominados 
ejemplos de formación) de los elementos junto con las 
clases a las que pertenecen, el problema es predecir la 
clase a la que pertenece un elemento nuevo. La clase 
del caso nuevo no se conoce, por lo que hay que utili¬ 
zar los demás atributos del caso para predecir la clase. 

La clasificación se puede llevar a cabo hallando reglas 
que dividan los datos dados en grupos disjuntos. Por 
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ejemplo, supóngase que una compañía de tarjetas de 
crédito quiera decidir si debe conceder una tarjeta a un 
solicitante. La compañía tiene amplia información sobre 
esa persona, como puede ser su edad, su nivel educati¬ 
vo, sus ingresos anuales y sus deudas actuales, la cual 
puede utilizar para adoptar una decisión. 

Parte de esta información puede ser importante para 
el valor de crédito del solicitante, mientras que puede 
que otra parte no lo sea. Para adoptar la decisión la com¬ 
pañía asigna un nivel de valor de crédito de excelente, 
bueno, mediano o malo a cada integrante de un con¬ 
junto de muestra de clientes actuales según su historial 
de pagos. Luego, la compañía intenta hallar reglas que 
clasifiquen a sus clientes actuales como excelentes, bue¬ 
nos, medianos o malos con base en la información sobre 
esas personas diferente de su historial de pagos actual 
(que no está disponible para los clientes nuevos). Con¬ 
sidérense sólo dos atributos: el nivel educativo (la titu¬ 
lación más alta conseguida) y los ingresos. Las reglas 
pueden ser de la forma siguiente: 

V persona P, P.titulación = máster and P.ingresos 
> 75000 => P.crédito = excelente 

V persona P, P.titulación = bachiller or 
(P.ingresos > 25000 and P.ingresos < 75000) 

=> P.crédito = bueno 

También aparecen reglas parecidas para los demás nive¬ 
les de valor de crédito (mediano y malo). 

El proceso de creación de clasificadores comienza 
con una muestra de los datos, denominada conjunto de 
formación. Para cada tupia del conjunto de formación 
ya se conoce la clase a la que pertenece. Por ejemplo, 
el conjunto de formación de las solicitudes de tarjetas 


de crédito pueden ser los clientes ya existentes, con su 
valor de crédito determinado a partir de su historial de 
pagos. Los datos actuales, o población, pueden consis¬ 
tir en toda la gente, incluida la que no es todavía clien¬ 
te. Hay varias maneras de crear clasificadores, como se 
verá. 

22.3.2.1. Clasificadores de árboles de decisión 

Los clasificadores de árboles de decisión son una téc¬ 
nica muy utilizada para la clasificación. Como sugiere 
el nombre, los clasificadores de árboles de decisión 
utilizan un árbol; cada nodo hoja tiene una clase aso¬ 
ciada, y cada nodo interno tiene un predicado (o, de 
manera más general, una función) asociado. La Figura 
22.6 muestra un ejemplo de árbol de decisión. 

Para clasificar un nuevo caso se empieza por la raíz 
y se recorre el árbol hasta alcanzar una hoja; en los nodos 
internos se evalúa el predicado (o la función) para el 
ejemplo de datos, para hallar a qué nodo hijo hay que 
ir. El proceso continúa hasta que se llega a un nodo hoja. 
Por ejemplo, si el nivel académico de la persona es de 
máster y sus ingresos son de 40K, partiendo de la raíz 
se sigue el arco etiquetado «máster», y desde allí el arco 
etiquetado «25K a 75K», hasta alcanzar una hoja. La 
clase de la hoja es «bueno», por lo que se puede prede¬ 
cir que el riesgo de crédito de esa persona es bueno. 

Creación de clasificadores de árboles de decisión 

La pregunta que se plantea es el modo de crear un cla¬ 
sificador de árboles de decisión, dado un conjunto de 
casos de formación. La manera más frecuente de hacer¬ 
lo es utilizar un algoritmo impaciente, que trabaja de 
manera recursiva, comenzando por la raíz y constru- 



excelente 

FIGURA 22.6. Árbol de clasificación. 
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yendo el árbol hacia abajo. Inicialmente sólo hay un 
nodo, la raíz, y todos los casos de formación están aso¬ 
ciados con ese nodo. 

En cada nodo, si todos o «casi todos» los ejemplos 
de formación asociados con el nodo pertenecen a la 
misma clase, el nodo se convierte en un nodo hoja aso¬ 
ciado con esa clase. En caso contrario, hay que selec¬ 
cionar un atributo de partición y condiciones de par¬ 
tición para crear nodos hijo. Los datos asociados con 
cada nodo hijo son el conjunto de ejemplos de forma¬ 
ción que satisfacen la condición de partición de ese 
nodo hijo. En el ejemplo elegido, se escoge el atribu¬ 
to titulación y se crean cuatro hijos, uno por cada valor 
de la titulación. Las condiciones para los cuatro nodos 
hijo son titulación = ninguna, titulación = bachiller, 
titulación = máster y titulación = doctorado, respecti¬ 
vamente. Los datos asociados con cada hijo son los 
ejemplos de formación asociados con ese hijo. En el 
nodo correspondiente a máster se escoge el atributo 
ingreso con el rango de valores dividido en los inter¬ 
valos 0 a 25.000, 25.000 a 50.000, 50.000 a 75.000 y 
más de 75.000. Los datos asociados con cada nodo son 
los ejemplos de formación con atributo titulación igual 
a máster y el atributo ingresos en cada uno de los ran¬ 
gos, respectivamente. Como optimización, ya que la 
clase para el rango de 25.000 a 50.000 y el rango de 
50.000 a 75.000 es el mismo bajo el nodo titulación 
= máster, se han unido los dos rangos en uno solo que 
va de 25.000 a 75.000. 

Las mejores particiones 

De manera intuitiva, al escoger una secuencia de atri¬ 
butos de partición, se comienza con el conjunto de todos 
los ejemplos de formación, que es «impuro» en el sen¬ 
tido de que contiene ejemplos de muchas clases, y se 
acaba con las hojas, que son «puras» en el sentido de 
que en cada hoja todos los ejemplos de formación per¬ 
tenecen a una única clase. Se verá brevemente el modo 
de medir cuantitativamente la pureza. Para evaluar la 
ventaja de escoger un atributo concreto y la condición 
para la partición de los datos en un nodo se mide la pure¬ 
za de los datos en los hijos resultantes de la partición 
según ese atributo. Se escogen el atributo y la condi¬ 
ción que producen la pureza máxima. 

La pureza de un conjunto S de ejemplos de forma¬ 
ción puede medirse cuantitativamente de varias mane¬ 
ras. Supóngase que hay k clases y que de los ejemplos 
en S la fracción de ejemplos de la clase i es p¡. Una medi¬ 
da de pureza, la medida de Gini, se define como 

Gini(S)= 1-Í p] 

i-1 

Cuando todos los ejemplos están en una sola clase, 
el valor de Gini es 0, mientras que alcanza su máximo 
(de 1 - l/k) si cada clase tiene el mismo número de ejem¬ 
plos. Otra medida de la pureza es la medida de la entro¬ 
pía, que se define como 


k 

Entropía(S) = - X p¡ logo p¡ 

i- 1 

El valor de la entropía es 0 si todos los ejemplos están 
en una sola clase y alcanza su máximo cuando cada cla¬ 
se tiene el mismo número de ejemplos. La medida de 
la entropía proviene de la teoría de la información. 

Cuando un conjunto S se divide en varios conjuntos 
S¡, i = 1,2,..., r, se puede medir la pureza del conjun¬ 
to de conjuntos resultante como: 

Pureza^, S 2 , . . ., S ,.) = X pureza(S ; ) 

Es decir, la pureza es la media ponderada de la pureza 
de los conjuntos S¡. La fórmula anterior puede utilizar¬ 
se tanto con la medida de la pureza de Gini como con 
la medida de la pureza de la entropía. 

La ganancia de información debida a una partición 
concreta de S en S¡, i = 1,2,..., r es, entonces, 

Ganancia-información^, ¡ 5j, S 2 ,.... S,.}) 

= pureza(S') - pureza(.Sj, S 2 ,, S r ) 

Las particiones en menor número de conjuntos son 
preferibles a las particiones en muchos conjuntos, ya 
que llevan a árboles de decisión más sencillos y signi¬ 
ficativos. El número de elementos en cada uno de los 
conjuntos S¡ también puede tenerse en cuenta; en caso 
contrario, que un conjunto S¡ tenga 0 elementos o 1 ele¬ 
mento supondría una gran diferencia en el número de 
conjuntos, aunque la partición fuera la misma para casi 
todos los elementos. El contenido de información de 
una partición concreta puede expresarse en términos de 
entropía como 


Contenido-información(S', {Sj, S 2 , 
f /Si/ , /Si/ 

-■ - x -T- log 2 ■ 


¡-i /S/ 


/S/ 


;S r }))= 


Todo esto lleva a una definición: La mejor partición 
para un atributo es la que da el máximo índice de 
ganancia de información, definido como 


Ganancia-información^, {Sj, S 2 ,..., S r }) 
Contenido-información(5, (5,, S 2 . S r }) 


Búsqueda de las mejores particiones 

Hay que averiguar el modo de hallar la mejor partición 
para un atributo. El modo de dividir un atributo depen¬ 
de del tipo de atributo. Los atributos pueden tener valo¬ 
res continuos, es decir, los valores se pueden ordenar 
de manera significativa para la clasificación, como la 
edad o los ingresos, o pueden ser categóricos, es decir, 
no tener ningún orden significativo, como los nombres 
de los departamentos o los de los países. No se espera 
que el orden de los nombres de los departamentos o el 
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de los países tenga ningún significado para la clasifica¬ 
ción. 

Generalmente, los atributos que son números (ente¬ 
ros o reales) se tratan como valores continuos y los atri¬ 
butos de cadenas de caracteres se tratan como categó¬ 
ricos, pero esto puede controlarlo el usuario del sistema. 
En el ejemplo escogido se ha tratado el atributo titula¬ 
ción como categórico y el atributo ingresos como valor 
continuo. 

En primer lugar se considera el modo de hallar las 
mejores particiones para los atributos con valores con¬ 
tinuos. Por sencillez sólo se considerarán particiones 
binarias de los atributos con valores continuos, es decir, 
particiones que den lugar a dos hijos. El caso de las par¬ 
ticiones múltiples es más complicado; véanse las notas 
bibliográficas para hallar referencias sobre este asunto. 

Para hallar la mejor partición binaria de un atributo 
con valores continuos, en primer lugar, se ordenan los 
valores del atributo en los ejemplos de formación. Lue¬ 
go se calcula la ganancia de información obtenida por 
la división en cada valor. Por ejemplo, si los ejemplos 
de formación tienen los valores 1, 10, 15 y 25 para un 
atributo, los puntos de partición considerados son 1, 10 
y 15; en cada caso, los valores menores o iguales que 
el punto de partición forman una partición y el resto de 
los valores forman la otra. La mejor partición binaria 
para el atributo es la partición que da la ganancia de 
información máxima. 

Para los atributos categóricos se pueden tener parti¬ 
ciones múltiples, con un hijo para cada valor del atri¬ 
buto. Esto funciona muy bien para los atributos cate¬ 
góricos con pocos valores diferentes, como la titulación 
o el sexo. No obstante, si el atributo tiene muchos valo¬ 
res diferentes, como los nombres de los departamentos 
en compañías grandes, la creación de un hijo para cada 
valor no es una buena idea. En esos casos se procura 
combinar varios valores en cada hijo para crear un núme¬ 
ro menor de hijos. Véanse las notas bibliográficas para 
hallar referencias al modo de hacerlo. 

Algoritmo de construcción del árbol de decisión 

La idea principal de la construcción de árboles de deci¬ 
sión es la evaluación de los diferentes atributos y de las 
distintas condiciones de partición y la selección del atri¬ 
buto y de la condición de partición que generen el índi¬ 
ce máximo de ganancia de información. El mismo pro¬ 
cedimiento funciona de manera recursiva en cada uno 
de los conjuntos resultantes de la partición, lo que hace 
que se construya de manera recursiva el árbol de deci¬ 
sión. Si los datos pueden clasificarse de manera per¬ 
fecta, la recursión se detiene cuando la pureza de un 
conjunto sea 0. No obstante, los datos suelen tener rui¬ 
do, o puede que un conjunto sea tan pequeño que no se 
justifique estadísticamente su partición. En ese caso, la 
partición se detiene cuando la pureza del conjunto es 
«bastante alta» y la clase de la hoja resultante se define 
como la clase de la mayoría de los elementos del con¬ 


junto. En general, las diferentes ramas del árbol pueden 
crecer hasta niveles diferentes. 

La Figura 22.7 muestra pseudocódigo para un pro¬ 
cedimiento recursivo de construcción de un árbol, que 
toma al conjunto de ejemplos de formación S como pará¬ 
metro. La recursión se detiene cuando el conjunto es lo 
bastante puro o el conjunto S es demasiado pequeño 
para que más particiones resulten estadísticamente sig¬ 
nificativas. Los parámetros S p y ó, definen los valores 
de corte para la pureza y el tamaño; puede que el siste¬ 
ma les dé valores predeterminados, que los usuarios 
pueden cancelar. 

Hay gran variedad de algoritmos de construcción de 
árboles de decisión y se esbozarán las características 
distintivas de unos cuantos. Véanse las notas biblio¬ 
gráficas para hallar más detalles. Con conjuntos de datos 
de tamaño muy grande la realización de particiones pue¬ 
de resultar muy costosa, ya que implica la realización 
repetida de copias. Por tanto, se han desarrollado varios 
algoritmos para minimizar el coste de E/S y el coste de 
computación cuando los datos de formación son mayo¬ 
res que la memoria disponible. 

Varios de los algoritmos también podan los subár¬ 
boles del árbol de decisión generado para reducir el 
exceso de ajuste: un subárbol tiene exceso de ajuste si 
se ha ajustado tanto a los detalles de los datos de for¬ 
mación que comete muchos errores de clasificación con 
otros datos. Se poda un subárbol sustituyéndolo por un 
nodo hoja. Hay varias heurísticas de poda; una utiliza 
parte de los datos de formación para construir el árbol 
y otra parte para comprobarlo. La heurística poda el 
subárbol si descubre que los errores de clasificación de 
los casos de prueba se reducirían si se sustituyera por 
un nodo hoja. 

Se pueden generar reglas de clasificación a partir de 
los árboles de decisión, si se desea. Para cada hoja se 
genera una regla de la manera siguiente: la parte izquier¬ 
da es la conjunción de todas las condiciones de parti¬ 
ción del camino hasta la hoja y la clase es la clase de la 
mayoría de los ejemplos de formación de la hoja. Un 
ejemplo de estas reglas de clasificación es 

titulación = máster and ingresos > 75.000 => excelente 


procedure CultivarÁrbol(S) 

Partición(S); 

procedure Partición (S) 

if (pureza[S) > Sp or ISI < ó 1 ) then 
return; 

for each atributo A 

evalúa las particiones según el atributo A; 

Utiliza la mejor partición hallada (para todos los atributos) 
para dividir S en S v S 2 ,..., S r ; 

for i = 1 , 2 ,..., r 
Partición (Sí); 

FIGURA 22.7. Construcción recursiva de un árbol de deci¬ 
sión. 
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22.3.2.2. Otros tipos de clasificadores 

Hay varios tipos de clasificadores aparte de los clasifi¬ 
cadores de árbol. Dos tipos que han resultado bastante 
útiles son los clasificadores de redes neuronales y los 
clasificadores bayesianos. Los clasificadores de redes 
neuronales utilizan los datos de formación para adies¬ 
trar redes neuronales artificiales. Hay gran cantidad de 
literatura sobre las redes neuronales y aquí no se habla¬ 
rá más de ellas. 

Los clasificadores bayesianos hallan la distribución 
de los valores de los atributos para cada clase de los 
datos de formación; cuando se da un nuevo caso, d. uti¬ 
lizan la información de la distribución para estimar, para 
cada clase Cj, la probabilidad de que el caso d pertenezca 
a la clase c r denotada por p(cjd), de la manera que aquí 
se describe. La clase con la probabilidad máxima se 
transforma en la clase predicha para el caso d. 

Para hallar la probabilidad p{cjd) de que el caso d 
esté en la clase Cj los clasificadores bayesianos utilizan 
el teorema de Bayes, que dice 

p{c d) =- 

P(d) 

donde p(d/cfi es la probabilidad de que se genere el caso 
d dada la clase c¡, p(cfi es la probabilidad de ocurrencia 
de la clase c ; y p(d) es la probabilidad de que ocurra el 
caso d. De éstas, p(d) puede ignorarse, ya que es igual 
para todas las clases, picfi no es más que la fracción de 
los casos de formación que pertenecen a la clase Cj. 

Hallar exactamente p(d/cfi resulta difícil, ya que exi¬ 
ge una distribución completa de los casos de c } . Para 
simplificar la tarea los clasificadores bayesianos inge¬ 
nuos dan por hecho que los atributos tienen distribu¬ 
ciones independientes y, por tanto, estiman 

Pid/cfi =p(d 1 \c j ) * p(d 2 \Cj) * ... * p(djcj) 

Es decir, la probabilidad de que ocurra el caso d es el 
producto de la probabilidad de ocurrencia de cada uno 
de los valores di del atributo d, dado que la clase es c¡. 

Las probabilidades p(djcfi proceden de la distribu¬ 
ción de los valores de cada atributo /, para cada clase 
Cj. Esta distribución se calcula a partir de los ejemplos 
de formación que pertenecen a cada clase c¡, la distri¬ 
bución suele aproximarse mediante un histograma. Por 
ejemplo, se puede dividir el rango de valores del atri¬ 
buto i en intervalos iguales y almacenar la fracción de 
casos de la clase c¡ que caen en cada intervalo. Dado un 
valor d¡ para el atributo i, el valor de p(djcfi es simple¬ 
mente la fracción de casos que pertenecen a la clase c ; 
que caen en el intervalo al que pertenece d¡. 

Una ventaja significativa de los clasificadores baye¬ 
sianos es que pueden clasificar los casos con valores de 
los atributos desconocidos y nulos; los atributos desco¬ 
nocidos o nulos simplemente se omiten del cálculo de 
probabilidades. Por el contrario, los clasificadores de 
árboles de decisión no pueden tratar de manera signifi¬ 


cativa las situaciones en que el caso que hay que clasi¬ 
ficar tiene un valor nulo para el atributo de partición uti¬ 
lizado para avanzar por el árbol de decisión. 

22.3.2.3. Regresión 

La regresión trata de la predicción de valores, no de 
clases. Dados los valores de un conjunto de variables, 

X, , X 2 ,..., X n , se desea predecir el valor de una variable 

Y. Por ejemplo, se puede tratar el nivel educativo como 
un número y los ingresos como otro número y, con base 
en estas dos variables, querer predecir la posibilidad de 
impago, que podría ser un porcentaje de probabilidad 
de impago o el importe impagado. 

Una manera de inferir los coeficientes a 0 , aa 2 ,.... 
a n tales que 

Y = í7q 4- a ^ * X^ 4- a 2 * X 2 4- ... 4 - a n * X n 

La búsqueda de ese polinomio lineal se denomina regre¬ 
sión lineal. En general, se quiere hallar una curva (defi¬ 
nida por un polinomio o por otra fórmula) que se ajus¬ 
te a los datos; el proceso también se denomina ajuste 
de la curva. 

El ajuste sólo puede ser aproximado, debido al rui¬ 
do de los datos o a que la relación no sea exactamente 
un polinomio, por lo que la regresión pretende hallar 
coeficientes que den el mejor ajuste posible. Hay téc¬ 
nicas estándar en estadística para hallar los coeficien¬ 
tes de regresión. Aquí no se estudiarán esas técnicas, 
pero las notas bibliográficas ofrecen referencias. 

22.3.3. Reglas de asociación 

Los comercios minoristas suelen estar interesados en 
las asociaciones entre los diferentes artículos que com¬ 
pra la gente. Ejemplos de esas asociaciones son: 

• Alguien que compra pan es bastante probable que 
compre también leche. 

• Una persona que compró el libro Fundamentos de 
bases de datos es bastante probable que también 
compre el libro Fundamentos de sistemas opera¬ 
tivos. 

La información de asociación puede utilizarse de varias 
maneras. Cuando un cliente compra un libro determi¬ 
nado puede que la librería en línea le sugiera los libros 
asociados. Puede que la tienda de alimentación decida 
colocar el pan cerca de la leche, ya que suelen com¬ 
prarse juntos, para ayudar a los clientes a hacer la com¬ 
pra más rápidamente. O puede que la tienda los colo¬ 
que en extremos opuestos del mostrador y coloque otros 
artículos asociados entre medias para inducir a la gen¬ 
te a comprar también esos artículos, mientras los clien¬ 
tes van de un extremo a otro del mostrador. Puede que 
una tienda que ofrece descuento en un artículo asocia¬ 
do no lo ofrezca en el otro, ya que, de todos modos, el 
cliente comprará el segundo artículo. 
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Reglas de asociación 

Un ejemplo de regla de asociación es 

pan => leche 

En el contexto de las compras de alimentación, la regla 
dice que los clientes que compran pan también tienden 
a comprar leche con una probabilidad elevada. Una regla 
de asociación debe tener una población asociada: la 
población consiste en un conjunto de casos. En el ejem¬ 
plo de la tienda de alimentación, la población puede 
consistir en todas las compras en la tienda de alimenta¬ 
ción; cada compra es un caso. En el caso de una libre¬ 
ría, la población puede consistir en toda la gente que 
realiza compras, independientemente del momento en 
que las hayan realizado. Cada consumidor es un caso. 
Aquí, el analista ha decidido que el momento de reali¬ 
zación de la compra no es significativo, mientras que, 
para el ejemplo de la tienda de alimentación, puede que 
el analista haya decidido concentrarse en cada compra, 
ignorando las diferentes visitas de un mismo cliente. 

Las reglas tienen un soporte, así como una confian¬ 
za asociados. Los dos se definen en el contexto de la 
población: 

• El soporte es una medida de la fracción de la 
población que satisface tanto el antecedente como 
el consecuente de la regla. 

Por ejemplo, supóngase que sólo el 0.001 por 
ciento de todas las compras incluyen leche y des¬ 
tornilladores. El soporte de la regla 

leche =s> destornilladores 

es bajo. Puede que la regla ni siquiera sea esta¬ 
dísticamente significativa —quizás solo hubiera 
una única compra que incluyera leche y destor¬ 
nilladores. Las empresas no suelen estar intere¬ 
sadas en las reglas que tienen un soporte bajo, ya 
que afectan a pocos clientes y no merece la pena 
prestarles atención. 

Por otro lado, si el 50 por ciento de las com¬ 
pras implica leche y pan, el soporte de las reglas 
que afecten al pan y a la leche (y a ningún otro 
artículo) es relativamente elevado, y puede que 
merezca la pena prestarles atención. El grado 
mínimo de soporte que se considera deseable 
exactamente depende de la aplicación. 

• La confianza es una medida de la frecuencia con 
que el consecuente es cierto cuando lo es el ante¬ 
cedente. Por ejemplo, la regla 

pan => leche 

tiene una confianza del 80 por ciento si el 80 por 
ciento de las compras que incluyen pan incluyen 
también leche. Las reglas con una confianza baja 
no son significativas. En las aplicaciones comer¬ 
ciales las reglas suelen tener confianzas signifi¬ 


cativamente menores del 100 por ciento, mien¬ 
tras que en otros campos, como la física, las reglas 
pueden tener confianzas elevadas. 

Hay que tener en cuenta que la confianza de 
pan => leche puede ser muy diferente de la con¬ 
fianza de leche => pan, aunque las dos tienen el 
mismo soporte. 

Búsqueda de reglas de asociación 

Para descubrir reglas de asociación de la forma 
h> h’ h 

primero hay que hallar conjuntos de elementos con 
soporte suficiente, denominados conjuntos grandes de 
elementos. En el ejemplo que se trata se hallan con¬ 
juntos de elementos que están incluidos en un número 
de casos lo bastante grande. En breve se verá el modo 
de calcular conjuntos grandes de elementos. 

Para cada conjunto grande de elementos se obtienen 
todas las reglas con confianza suficiente que afecten a 
todos los elementos del conjunto y sólo a ellos. Para 
cada conjunto grande de elementos S se obtiene una 
regla S - s =$> s para cada subconjunto s C S, siempre 
que S - s =$> s tenga confianza suficiente; la confianza 
de la regla la da el soporte de 5 dividido por el soporte 
de S. 

Ahora se considerará el modo de generar todos los 
conjuntos grandes de elementos. Si el número de con¬ 
juntos de elementos posibles es pequeño, basta con un 
solo paso por los datos para detectar el nivel de soporte 
de todos los conjuntos. Se lleva una cuenta, con valor ini¬ 
cial 0, para cada conjunto de elementos. Cuando se cap¬ 
tura el registro de una compra, la cuenta se incrementa 
para cada conjunto de elementos tal que todos los ele¬ 
mentos del conjunto estén contenidos en la compra. Por 
ejemplo, si una compra incluye los elementos a,hy c, se 
incrementará el contador para {a}, \h\, {c}, ¡ a, h ¡, j h, 
c}, ¡ a, c } y {a, b, c}. Los conjuntos con un contador lo 
bastante elevado al final del pase se corresponden con los 
elementos que tienen un grado de asociación elevado. 

El número de conjuntos crece de manera exponen¬ 
cial, lo que hace inviable el proceso que se acaba de des¬ 
cribir si el número de elementos es elevado. Afortuna¬ 
damente, casi todos los conjuntos tienen normalmente 
un soporte muy bajo; se han desarrollado optimizacio¬ 
nes para no considerar la mayor parte de esos conjun¬ 
tos. Estas técnicas utilizan varios pases por la base de 
datos y sólo consideran algunos conjuntos en cada pase. 

En la técnica a priori para la generación de conjun¬ 
tos de artículos grandes sólo se consideran en el primer 
pase los conjuntos con un solo elemento. En el segun¬ 
do pase se consideran los conjuntos con dos artículos, 
etcétera. 

Al final de cada pase todos los conjuntos con sopor¬ 
te suficiente se consideran conjuntos grandes de ele¬ 
mentos. Los conjuntos que se ha hallado que tienen 
demasiado poco soporte al final de cada pase se elimi- 
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nan. Una vez eliminado un conjunto no hace falta con¬ 
siderar ninguno de sus superconjuntos. En otros térmi¬ 
nos, en el pase i sólo hay que contar el soporte de los 
conjuntos de tamaño i tales que se haya hallado que 
todos sus subconjuntos tienen un soporte lo bastante 
elevado; basta con probar todos los subconjuntos de 
tamaño i - 1 para asegurase de que se cumple esta pro¬ 
piedad. Al final del pase i se halla que ningún conjunto 
de tamaño i tiene el soporte suficiente, por lo que no 
hace falta considerar ningún conjunto de tamaño i + 1. 
Entonces, el cálculo se termina. 

22.3.4. Otros tipos de asociación 

El uso de meras reglas de asociación tiene varios incon¬ 
venientes. Uno de los principales es que muchas aso¬ 
ciaciones no son muy interesantes, ya que pueden pre¬ 
decirse. Por ejemplo, si mucha gente compra cereales 
y mucha gente compra pan, se puede predecir que un 
número bastante grande de personas comprará las dos 
cosas, aunque no haya ninguna relación entre las dos 
compras. Lo que resultaría interesante es una desvia¬ 
ción de la ocurrencia conjunta de las dos compras. En 
términos estadísticos, se buscan correlaciones entre los 
artículos; las correlaciones pueden ser positivas, en las 
que la ocurrencia conjunta es superior a lo esperado, o 
negativa, en la que los elementos ocurren conjuntamente 
menos frecuentemente de lo predicho. Se puede con¬ 
sultar cualquier libro de texto estándar de estadística 
para hallar más información sobre las correlaciones. 

Otra clase importante de aplicaciones de recopila¬ 
ción de datos son las asociaciones de secuencias (o 
correlaciones). Las series de datos temporales, como las 
cotizaciones bursátiles en una serie de días, constituyen 
un ejemplo de datos de secuencias. Los analistas bur¬ 
sátiles desean hallar asociaciones entre las secuencias 
de cotizaciones. Un ejemplo de asociación de este tipo 
es la regla siguiente: «Siempre que las tasas de interés 
de los bonos suben, las cotizaciones bursátiles bajan en 
un plazo de dos días». El descubrimiento de esta aso¬ 
ciación entre secuencias puede ayudar a adoptar deci¬ 
siones de inversión inteligentes. Véanse las notas biblio¬ 
gráficas para hallar referencias a la investigación en este 
campo. 

Las desviaciones de las estructuras temporales sue¬ 
len resultar interesantes. Por ejemplo, si una empresa 
ha estado creciendo a una tasa constante cada año, una 
desviación de la tasa de crecimiento habitual resulta sor¬ 
prendente. Si las ventas de ropa de invierno bajan en 
verano, ya que puede predecirse con base en los años 
anteriores, una desviación que no se pudiera predecir a 


partir de la experiencia pasada se consideraría intere¬ 
sante. Las técnicas de recopilación pueden hallar des¬ 
viaciones de lo esperado con base en las estructuras tem¬ 
porales o secuenciales pasadas. Véanse las notas 
bibliográficas para hallar referencias a la investigación 
en este campo. 

22.3.5. Agrupamiento 

De manera intuitiva, el agrupamiento hace referencia al 
problema de hallar agrupaciones de puntos en los datos 
dados. El problema del agrupamiento puede formali¬ 
zarse de varias maneras a partir de las métricas de dis¬ 
tancias. Una manera es formularlo como el problema 
de agrupar los puntos en k conjuntos (para un k dado) 
de modo que la distancia media de los puntos al cen¬ 
troide de su agrupación asignada sea mínima 5 . Otra 
manera es agrupar los puntos de modo que la distancia 
media entre cada par de puntos de cada agrupación sea 
mínima. Hay otras definiciones; véanse las notas biblio¬ 
gráficas para hallar más detalles. Pero la intuición sub¬ 
yacente a todas estas definiciones es agrupar los puntos 
parecidos en un único conjunto. 

Otro tipo de agrupamiento aparece en los sistemas 
de clasificaciones de la biología. (Esos sistemas de cla¬ 
sificación no intentan predecir las clases, sino agmpar 
los elementos relacionados.) Por ejemplo, los leopar¬ 
dos y los seres humanos se agrupan bajo la clase mamí¬ 
feros, mientras que los cocodrilos y las serpientes se 
agrupan bajo los reptiles. Tanto los mamíferos como los 
reptiles están bajo la clase común de los cordados. La 
agrupación de los mamíferos tiene subagrupaciones, 
como los carnívoros y los primates. Por tanto, se tiene 
un agrupamiento jerárquico. Dadas las característi¬ 
cas de las diferentes especies, los biólogos han creado 
un esquema complejo de agrupamiento jerárquico que 
agrupa las especies relacionadas en diferentes niveles 
de la jerarquía. 

El agrupamiento jerárquico también resulta útil en 
otros dominios; para agrupar documentos, por ejemplo. 
Los sistemas de directorio de Internet (como el de 
Yahoo) agrupan los documentos relacionados de mane¬ 
ra jerárquica (véase el Apartado 22.5.5). Los algoritmos 
de agrupamiento jerárquico pueden clasificarse como 
algoritmos de agrupamiento aglomerativo, que 
comienzan creando agrupaciones pequeñas y luego 
crean los niveles superiores, o como algoritmos de agru¬ 
pamiento divisivo, que primero crean los niveles supe¬ 
riores del agrupamiento jerárquico y luego refinan cada 
agrupación resultante en agrupaciones de niveles infe¬ 
riores. 


5 El centroide de un conjunto de puntos se define como un punto 
cuyas coordenadas en cada dimensión son el promedio de las coor¬ 
denadas de todos los puntos de ese conjunto en esa dimensión. Por 
ejemplo, en dos dimensiones, el centroide de un conjunto de puntos 

{(Xi,J/i), (x 2 ,y 2 ),..., (x n ,y n )} viene dado por ( “ i ;' X| , - i ~ l3 ' i ). 
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La comunidad estadística ha estudiado extensamen¬ 
te los agrupamientos. La investigación en bases de datos 
ha proporcionado algoritmos escalables de agmpamiento 
que pueden agrupar conjuntos de datos de tamaño muy 
grande (que puede que no quepan en la memoria). El 
algoritmo de agrupamiento Birch es un algoritmo de este 
tipo. De manera intuitiva, los puntos de datos se inser¬ 
tan en una estructura arbórea multidimensional (basada 
en los árboles R descritos en el Apartado 23.3.5.3) y son 
llevados a los nodos hoja correspondientes de acuerdo 
con su cercanía a los puntos representativos de los nodos 
internos del árbol. Los puntos próximos, por tanto, se 
agrupan en los nodos hoja, y se resumen si hay más pun¬ 
tos de los que caben en la memoria. El procesamiento 
posterior a la inserción de todos los puntos da el agru¬ 
pamiento global deseado. Véanse las notas bibliográfi¬ 
cas para hallar las referencias al algoritmo Birch y a otras 
técnicas de agmpamiento, incluidos los algoritmos para 
el agrupamiento jerárquico. 

Una aplicación interesante del agrupamiento es la 
predicción de las películas nuevas (o de los libros nue¬ 
vos, o de la música nueva) que es probable que intere¬ 
sen a una persona, con base en: 

1. Las preferencias cinematográficas pasadas de esa 
persona 

2. Otras personas con preferencias pasadas parecidas 

3. Las preferencias de esa gente entre las películas 
nuevas 

Un enfoque de este problema es el siguiente. Para hallar 
gente con preferencias anteriores parecidas se crean 
agrupaciones de personas de acuerdo con sus preferen¬ 
cias cinematográficas. La exactitud del agrupamiento 
puede mejorarse agrupando previamente las películas 
por su parecido, de modo que, aunque la gente no haya 
visto las mismas películas, se agruparán si han visto 
películas parecidas. Se puede repetir el agrupamiento, 
agrupando alternativamente gente y películas hasta que 
se alcance un equilibrio. Dado un nuevo usuario, se halla 
una agrupación de usuarios lo más parecidos posibles 
a él, con base en las preferencias del usuario por las pelí¬ 
culas que ya ha visto. Luego se predice que las pelícu¬ 
las de las agrupaciones de películas que son populares 
en la agrupación de ese usuario es probable que resul¬ 
ten interesantes para el nuevo usuario. De hecho, este 
problema es un caso de filtrado colaborativo, en el que 
los usuarios colaboran en la tarea de filtrado de la infor¬ 
mación para hallar información de interés. 


22.3.6. Otros tipos de recopilación 

Las técnicas de recopilación de datos para la recopi¬ 
lación de texto en documentos de texto. Por ejemplo, 
hay herramientas que forman agrupaciones de las pági¬ 
nas que ha visitado un usuario; esto ayuda a los usua¬ 
rios cuando examinan su historial de exploración para 
hallar las páginas que han visitado anteriormente. La 
distancia entre las páginas puede basarse, por ejemplo, 
en las palabras frecuentes en esas páginas (véase el 
Apartado 22.5.1.3). Otra aplicación es la clasificación 
automática de las páginas en directorios Web, de acuer¬ 
do con su parecido con otras páginas (véase el Aparta¬ 
do 22.5.5). 

Los sistemas de visualización de datos ayudan a 
los usuarios a examinar grandes volúmenes de datos y 
a detectar visualmente las estructuras. Las exhibicio¬ 
nes visuales de datos —como los mapas, los gráficos 
y otras representaciones gráficas— permiten que los 
datos se presenten a los usuarios de manera compacta. 
Una sola pantalla gráfica puede codificar tanta infor¬ 
mación como un número mucho mayor de pantallas de 
texto. Por ejemplo, si el usuario desea averiguar si los 
problemas de producción en las factorías están corre¬ 
lacionadas con su ubicación se pueden codificar las ubi¬ 
caciones problemáticas en un color especial —por ejem¬ 
plo, rojo— en un mapa. El usuario puede descubrir 
rápidamente las ubicaciones en las que se dan los pro¬ 
blemas. El usuario puede así formular hipótesis sobre 
el motivo de que los problemas se produzcan en esas 
ubicaciones y verificarlas cuantitativamente con la base 
de datos. 

Otro ejemplo más: la información sobre los valores 
puede codificarse como colores y mostrarse con sólo un 
píxel de área de pantalla. Para detectar las asociaciones 
entre pares de elementos se puede utilizar una matriz 
bidimensional de píxeles en la que cada fila y cada 
columna representen un elemento. El porcentaje de tran¬ 
sacciones que compran los dos elementos puede codi¬ 
ficarse por la intensidad del color de los píxeles. Los 
elementos con asociaciones elevadas aparecerán en la 
pantalla como píxeles brillantes —fáciles de detectar 
contra el fondo más oscuro. 

Los sistemas de visualización de datos no detectan 
de manera automática las estructuras, sino que propor¬ 
cionan soporte del sistema para que los usuarios las 
detecten. Dado que los seres humanos son muy buenos 
en la detección de estructuras visuales, la visualización 
de los datos es un componente importante de la recopi¬ 
lación de datos. 
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22.4. ALMACENAMIENTO DE DATOS 


Las grandes empresas tienen presencia en muchos luga¬ 
res, cada uno de los cuales puede generar un gran volu¬ 
men de datos. Por ejemplo, las cadenas de tiendas mino¬ 
ristas tienen centenares o millares de tiendas, mientras 
que las compañías de seguros pueden tener datos de milla¬ 
res de oficinas locales. Además, las organizaciones gran¬ 
des tienen una estructura compleja de organización inter¬ 
na y, por tanto, puede que los diferentes datos se hallen 
en ubicaciones diferentes, en sistemas operativos distin¬ 
tos o bajo esquemas diferentes. Por ejemplo, puede que 
los datos de los problemas de fabricación y los datos 
sobre las quejas de los clientes estén almacenados en 
diferentes sistemas de bases de datos. Los encargados de 
adoptar las decisiones empresariales necesitan tener acce¬ 
so a la información de todas esas fuentes. La formula¬ 
ción de consultas a cada una de las fuentes es a la vez 
engorroso e ineficiente. Además, puede que los orígenes 
de datos sólo almacenen los datos actuales, mientras que 
es posible que los encargados de adoptar las decisiones 
empresariales necesiten tener acceso también a datos 
anteriores, por ejemplo, información sobre la manera en 
que se han modificado las pautas de compra el año pasa¬ 
do puede resultar de gran importancia. Los almacenes 
de datos proporcionan una solución a estos problemas. 

Los almacenes de datos (data warehouses) son 
depósitos (o archivos) de información reunida de varios 
orígenes, almacenada bajo un esquema unificado en un 
solo sitio. Una vez reunida, los datos se almacenan 
mucho tiempo, lo que permite el acceso a datos históri¬ 
cos. Así, los almacenes de datos proporcionan a los usua¬ 
rios una sola interfaz consolidada con los datos, lo que 
hace más fáciles de escribir las consultas de ayuda a la 
toma de decisiones. Además, al tener acceso a la infor¬ 
mación para la ayuda de la toma de decisiones desde un 


almacén de datos, el encargado de adoptar las decisio¬ 
nes se asegura de que los sistemas de procesamiento en 
línea de las transacciones no se vean afectados por la 
carga de trabajo de la ayuda de la toma de decisiones. 

22.4.1. Componentes de los almacenes 
de datos 

La Figura 22.8 muestra la arquitectura de un almacén 
de datos típico e ilustra la recogida de los datos, su alma¬ 
cenamiento y el soporte de las consultas y del análisis 
de datos. Entre los problemas que hay que resolver al 
crear un almacén de datos están los siguientes: 

• Momento y modo de la recogida de datos. En 
una arquitectura dirigida por los orígenes para 
la recogida de los datos, los orígenes de los datos 
transmiten la información nueva, bien, de mane¬ 
ra continua (a medida que se produce el procesa¬ 
miento de las transacciones) o de manera perió¬ 
dica (de noche, por ejemplo). En una arquitectura 
dirigida por el destino, el almacén de datos envía 
de manera periódica solicitudes de datos nuevos 
a los orígenes de datos. 

A menos que las actualizaciones de los oríge¬ 
nes de datos se repliquen en el almacén de datos 
mediante un compromiso de dos fases, el almacén 
de datos nunca estará actualizado respecto a los 
orígenes de datos. El compromiso de dos fases sue¬ 
le resultar demasiado costoso para ser una opción 
aceptable, por lo que los almacenes de datos sue¬ 
len tener datos ligeramente desactualizados. Eso, 
no obstante, no suele suponer un problema para 
los sistemas de ayuda a la toma de decisiones. 



FIGURA 22.8. Arquitectura de los almacenes de datos. 
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Selección del esquema. Es probable que los orí¬ 
genes de datos que se han creado de manera inde¬ 
pendiente tengan esquemas diferentes. De hecho, 
puede que utilicen diferentes modelos de datos. 
Parte de la labor de los almacenes de datos es lle¬ 
var a cabo la integración de los esquemas y con¬ 
vertir los datos al esquema integrado antes de 
almacenarlos. En consecuencia, los datos alma¬ 
cenados en el almacén de datos no son una mera 
copia de los datos de los orígenes de datos. Por el 
contrario, se pueden considerar como una vista 
materializada de los datos de los orígenes de datos. 

Limpieza de los datos. La labor de corregir y rea¬ 
lizar un procesamiento previo de los datos se deno¬ 
mina limpieza de los datos. Los orígenes de datos 
suelen entregar datos con numerosas inconsisten¬ 
cias de carácter menor, que pueden corregirse. Por 
ejemplo, los nombres suelen estar mal escritos y 
puede que las direcciones tengan mal escritos los 
nombres de la calle, del distrito o de la ciudad, o 
puede que los códigos postales se hayan introdu¬ 
cido de manera incorrecta. Esto puede corregirse 
en un grado razonable consultando una base de 
datos de los nombres de las calles y de los códi¬ 
gos postales de cada ciudad. Las listas de direc¬ 
ciones recogidas de varios orígenes pueden tener 
duplicados que haya que eliminar en una opera¬ 
ción de mezcla-purga. Los registros de varias 
personas de una misma casa pueden agruparse 
para que sólo se realice a cada casa un envío de 
correo; esta operación se denomina domiciliación. 

Propagación de las actualizaciones. Las actua¬ 
lizaciones de las relaciones en los orígenes de 
datos deben propagarse a los almacenes de datos. 
Si las relaciones en los almacenes de datos son 
exactamente las mismas que en los orígenes de 
datos, la propagación es directa. En caso contra¬ 
rio, el problema de la propagación de las actuali¬ 
zaciones es básicamente el problema del mante¬ 
nimiento de las vistas que se estudió en el 
Apartado 14.5. 

Resúmenes de los datos. Los datos brutos gene¬ 
rados por un sistema de procesamiento de tran¬ 
sacciones pueden ser demasiado grandes para 
almacenarlos en línea. No obstante, se pueden res¬ 
ponder muchas consultas manteniendo únicamente 
datos resumen obtenidos por agregación de las 
relaciones, en lugar de mantener las relaciones 
enteras. Por ejemplo, en lugar de almacenar los 
datos de cada venta de ropa, se pueden almacenar 
las ventas totales de ropa por nombre de artículo 
y por categoría. 

Supóngase que una relación r ha sido sustitui¬ 
da por una relación resumen s. Todavía se puede 
permitir a los usuarios que planteen consultas 


como si la relación r estuviera disponible en línea. 
Si la consulta sólo necesita datos resumidos, pue¬ 
de que sea posible transformarla en una equiva¬ 
lente utilizando s en lugar de r; véase el Aparta¬ 
do 14.5. 

22.4.2. Esquemas de los almacenes de datos 

Los almacenes de datos suelen tener esquemas diseña¬ 
dos para el análisis de los datos y emplean herramien¬ 
tas como las herramientas OLAP. Por tanto, los datos 
suelen ser datos multidimensionales, con atributos de 
dimensión y atributos de medida. Las tablas que con¬ 
tienen datos multidimensionales se denominan tablas 
de hechos y suelen ser muy grandes. Las tablas que 
registran información de ventas de una tienda minoris¬ 
ta, con una tupia para cada artículo a la venta, son un 
ejemplo típico de tablas de hechos. Las dimensiones de 
la tabla ventas incluyen lo que es el artículo (general¬ 
mente un identificador del artículo como el utilizado en 
los códigos de barras), la fecha en que se ha vendido, 
la ubicación (tienda) en que se vendió, el cliente que lo 
ha comprado, etcétera. Entre los atributos de medida 
pueden estar el número de artículos vendidos y el pre¬ 
cio de cada artículo. 

Para minimizar los requisitos de almacenamiento los 
atributos de dimensiones suelen ser identificadores bre¬ 
ves que actúan de claves externas en otras tablas deno¬ 
minadas tablas de dimensiones. Por ejemplo, la tabla 
de hechos ventas tiene los atributos id-artículo, id-tien¬ 
da, id-cliente y fecha y los atributos de medida núme¬ 
ro y precio. El atributo id-tiencla es una clave externa 
en la tabla de dimensiones tienda, que tiene otros atri¬ 
butos como la ubicación de la tienda (ciudad, estado, 
país). El atributo id-artículo de la tabla ventas es una 
clave externa de la tabla de dimensiones info-artículo, 
que contiene información como el nombre del artículo, 
la categoría a la que pertenece el artículo y otros deta¬ 
lles del artículo como el color y la talla. El atributo id- 
cliente es una clave externa de la tabla cliente, que con¬ 
tiene atributos como el nombre y la dirección de los 
clientes. También se puede ver el atributo fecha como 
clave externa de la tabla info-fecha, que da el mes, el 
trimestre y el año de cada fecha. 

El esquema resultante aparece en la Figura 22.9. Un 
esquema así, con una tabla de hechos, varias tablas de 
dimensiones y claves externas procedentes de la tabla 
de hechos en las tablas de dimensiones, se denomina 
esquema en estrella. Los diseños complejos de alma¬ 
cenes de datos pueden tener varios niveles de tablas de 
dimensiones; por ejemplo, la tabla info-artículo puede 
tener un atributo id-fabricante que es clave externa en 
otra tabla que da detalles del fabricante. Estos esque¬ 
mas se denominan esquemas en copo de nieve. Los dise¬ 
ños complejos de almacenes de datos pueden tener tam¬ 
bién más de una tabla de hechos. 
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información-artículo almacén 



FIGURA 22.9. Esquema en estrella de un almacén de datos. 


22.5. SISTEMAS DE RECUPERACIÓN DE LA INFORMACIÓN 


El campo de la recuperación de la información se ha 

desarrollado en paralelo con el campo de las bases de 
datos. En el modelo tradicional utilizado en el campo 
de la recuperación de la información, la información se 
organiza en documentos, y se da por supuesto que hay 
un gran número de documentos. Los datos contenidos 
en los documentos están sin estructurar, sin ningún 
esquema asociado. El proceso de recuperación de la 
información consiste en localizar los documentos rele¬ 
vantes, en función de lo aportado por los usuarios, como 
pueden ser palabras clave o documentos de ejemplo. 

La Web proporciona una manera adecuada de llegar 
a las fuentes de información y de interactuar con ellas 
a través de Internet. No obstante, un problema persis¬ 
tente que afronta la Web es la explosión de la informa¬ 
ción almacenada, con poca orientación para ayudar a 
los usuarios a localizar lo que es interesante. La recu¬ 
peración de la información ha desempeñado un papel 
crítico en la transformación de la Web en una herra¬ 
mienta productiva y útil, especialmente para los inves¬ 
tigadores. 

Los ejemplos tradicionales de recuperación de la 
información son los catálogos en línea de las bibliote¬ 
cas y los sistemas de gestión en línea de los documen¬ 
tos como los que almacenan los artículos de los perió¬ 
dicos. Los datos en esos sistemas están organizados 
como un conjunto de documentos', los artículos de un 
periódico o las entradas de un catálogo (en el catálogo 
de una biblioteca) son ejemplos de documentos. En el 
contexto de la Web, cada página HTML suele conside¬ 
rarse un documento. 


Puede que el usuario de uno de estos sistemas desee 
recuperar un documento concreto o una clase de docu¬ 
mentos determinada. Los documentos buscados suelen 
describirse mediante un conjunto de palabras clave; 
por ejemplo, las palabras clave «sistema de bases de 
datos» pueden utilizarse para localizar libros sobres sis¬ 
temas de bases de datos, y las palabras clave «bolsa» y 
«escándalo» pueden utilizarse para localizar artículos 
sobre escándalos bursátiles. Los documentos tienen aso¬ 
ciados conjuntos de palabras clave, y se recuperan los 
documentos cuyas palabras clave contienen las propor¬ 
cionadas por el usuario. 

La recuperación de información basada en las pala¬ 
bras clave no sólo se puede utilizar para recuperar datos 
textuales, sino también para recuperar otros tipos de 
datos, como los datos de vídeo o de audio, que tengan 
asociadas palabras clave descriptivas. Por ejemplo, una 
película de vídeo puede tener asociadas palabras clave 
como su título, su director, sus actores, el tipo de pelí¬ 
cula, etcétera. Hay varias diferencias entre este mode¬ 
lo y los modelos utilizados en los sistemas tradiciona¬ 
les de bases de datos. 

• Los sistemas de bases de datos tratan varias ope¬ 
raciones que no se abordan en los sistemas de recu¬ 
peración de la información. Por ejemplo, los siste¬ 
mas de bases de datos tratan con las actualizaciones 
y con los requisitos transaccionales asociados de 
control de la concurrencia y la durabilidad. Estos 
asuntos se consideran menos importantes en los sis¬ 
temas de recuperación de la información. De mane- 
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ra parecida, los sistemas de bases de datos tratan 
con información estructurada organizada con mode¬ 
los de datos relativamente complejos (como el 
modelo relacional o los modelos de datos orienta¬ 
dos a los objetos), mientras que los sistemas de 
recuperación de la información han empleado tra¬ 
dicionalmente un modelo mucho más sencillo, en 
el que la información de la base de datos se orga¬ 
niza sencillamente como un conjunto de docu¬ 
mentos sin estructurar. 

• Los sistemas de recuperación de la información 
tratan varios aspectos que no se han abordado de 
manera adecuada en los sistemas de bases de datos. 
Por ejemplo, el campo de la recuperación de la 
información ha tratado los problemas de la gestión 
de documentos sin estructurar, como la búsqueda 
aproximada mediante palabras clave y la ordena¬ 
ción de los documentos por su grado estimado de 
importancia para la consulta. 

22.5.1. Búsqueda por palabras clave 

Los sistemas de recuperación de la información suelen 
permitir las expresiones de consulta formadas median¬ 
te palabras clave y las conectivas lógicas y, o y no. Por 
ejemplo, un usuario puede pedir todos los documentos 
que contengan las palabras clave «motocicleta y man¬ 
tenimiento», o los documentos que contienen las pala¬ 
bras clave «computadora o microprocesador», o inclu¬ 
so los documentos que contienen la palabra clave 
«computadora pero no base de datos». Se da por supues¬ 
to que una consulta que contenga las palabras clave sin 
ninguno de las conectivas indicados tiene y conectan¬ 
do las palabras clave de manera implícita. 

En la recuperación de texto completo se conside¬ 
ra que todas las palabras de cada documento son pala¬ 
bras clave. Para los documentos no estructurados la 
recuperación de texto completo resulta fundamental, 
ya que puede que no haya información sobre las pala¬ 
bras del documento que son palabras clave. Se utili¬ 
zará la palabra término para hacer referencia a las 
palabras de los documentos, ya que todas las palabras 
son palabras clave. 

En su forma más sencilla los sistemas de recupera¬ 
ción de la información buscan y devuelven todos los 
documentos que contienen todas las palabras clave de 
la consulta, si es que no tiene conectivas; las conecti¬ 
vas se manejan de la forma esperada. Los sistemas más 
sofisticados estiman la importancia de los documentos 
para la consulta de modo que se puedan mostrar por 
orden de la importancia estimada. Estos sistemas utili¬ 
zan información sobre las apariciones de los términos, 
así como la información de los hipervínculos para esti¬ 
mar la importancia; los apartados 22.5.1.1 y 22.5.1.2 
esbozan el modo de hacerlo. El Apartado 22.5.1.3 esbo¬ 
za el modo de definir el parecido entre los documentos 
y su empleo para la búsqueda. Algunos sistemas tam¬ 
bién intentan ofrecer un conjunto mejor de respuestas 


utilizando el significado de los términos, en vez de limi¬ 
tarse a sus apariciones sintácticas, como se describe en 
el Apartado 22.5.1.4. 

22.5.1.1. Clasificación por la importancia 
mediante el empleo de términos 

El conjunto de los documentos que satisfacen una expre¬ 
sión de consulta puede ser muy grande; en concreto, 
hay miles de millones de documentos en la Web y la 
mayor parte de las consultas por palabras clave en los 
motores de búsqueda de la Web hallan centenares de 
millares de documentos que contienen esas palabras cla¬ 
ve. La recuperación de texto completo agrava este pro¬ 
blema: cada documento puede contener muchos térmi¬ 
nos, incluso términos que sólo se mencionan de pasada 
se tratan de manera equivalente a documentos en los 
que el término sí es importante. En consecuencia, pue¬ 
de que se recuperen documentos irrelevantes. 

Por tanto, los sistemas de recuperación de la infor¬ 
mación estiman la importancia para la consulta de los 
documentos y sólo devuelven como respuestas los docu¬ 
mentos con una clasificación más elevada. La clasifi¬ 
cación por la importancia no es una ciencia exacta, pero 
hay algunos enfoques bien aceptados. 

El primer punto que hay que abordar es, dado un tér¬ 
mino concreto t , la importancia para el término de un 
documento dado d. Un enfoque es utilizar el número de 
apariciones del término en el documento como medida 
de su importancia, con la suposición de que es proba¬ 
ble que los términos importantes se mencionen muchas 
veces en el documento. El mero recuento del número 
de apariciones de un término no suele ser un buen indi¬ 
cador: en primer lugar, el número de apariciones depen¬ 
de de la longitud del documento y, en segundo lugar, 
puede que un documento que contenga diez aparicio¬ 
nes de un término no tenga diez veces la importancia 
de un documento que contenga una sola aparición. 

Un modo de medir i(d, t), la importancia de un docu¬ 
mento d para un término t, es 


i(d, t ) = log 



n(d, t ) \ 
n(d) ) 


donde n(d) denota el número de términos del documento 
y n(d, t) denota el número de apariciones del término t 
en el documento d. Obsérvese que esta métrica tiene en 
cuenta la longitud del documento. La importancia cre¬ 
ce con el número de apariciones del término en el docu¬ 
mento, aunque no es directamente proporcional al núme¬ 
ro de apariciones. 

Muchos sistemas refinan esta métrica empleando otra 
información. Por ejemplo, si el término aparece en el 
título, o en la lista de autores o en el resumen, el docu¬ 
mento se considera más importante para el término. De 
manera parecida, si la primera aparición del término se 
produce muy avanzado el documento, puede que el 
documento se considere menos importante que si apa- 
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rece por primera vez al principio del documento. Las 
ideas anteriores pueden formalizarse mediante exten¬ 
siones de la fórmula que se ha mostrado para i(d, t). En 
la comunidad de recuperación de la información la 
importancia de un documento para un término se deno¬ 
mina frecuencia del término, independientemente de 
la fórmula concreta utilizada. 

Una consulta C puede contener varias palabras cla¬ 
ve. La importancia de un documento para una consulta 
con dos o más palabras clave se estima combinando las 
medidas de importancia del documento para cada pala¬ 
bra clave. Una manera sencilla de combinar las medi¬ 
das es sumarlas. No obstante, no todos los términos uti¬ 
lizados como palabras clave son iguales. Supóngase que 
una consulta utiliza dos términos, uno de los cuales apa¬ 
rece con frecuencia, como «Web», y otro que es menos 
frecuente, como «Silberschatz». Un documento que con¬ 
tenga «Silberschatz» pero no «Web» debería clasificar¬ 
se por encima de otro que contuviera «Web» pero no 
«Silberschatz». 

Para solucionar este problema se asignan pesos a los 
términos empleando la frecuencia inversa de los docu¬ 
mentos, definida como Vn(t), donde n(t) denota el núme¬ 
ro de documentos (entre los indexados por el sistema) 
que contienen el término t. La importancia de un docu¬ 
mento d para un conjunto de términos Q se define como 


i(d,Q) = I 


- r(d, i) 


t£Q n(t) 


Esta medida puede retinarse aún más si se permite a los 
usuarios especificar los pesos p(t) de los términos de la 
consulta, en cuyo caso los pesos especificados por los 
usuarios se tienen también en cuenta empleando p(t)/n(t ) 
en lugar de \/n(t). 

Casi todos los documentos de texto (en español) con¬ 
tienen palabras como «y», «o», «un», etcétera y, por 
tanto, estas palabras resultan inútiles para propósitos de 
consulta, ya que su frecuencia inversa de documentos 
es extremadamente baja. Los sistemas de recuperación 
de la información definen un conjunto de palabras, deno¬ 
minadas palabras de parada, que contienen aproxi¬ 
madamente cien de las palabras más frecuentes, y eli¬ 
minan este conjunto del documento al indexarlo; estas 
palabras no se utilizan como palabras clave, y se des¬ 
cartan si se hallan entre las palabras proporcionadas por 
los usuarios. 

Otro factor que se tiene en cuenta cuando una con¬ 
sulta contiene varios términos es la proximidad de los 
términos en el documento. Si los términos aparecen cer¬ 
canos entre sí en el documento, el documento se clasi¬ 
ficará en una posición más elevada que si aparecen muy 
separados. La fórmula de i(d,Q ) puede modificarse para 
tener en cuenta la proximidad. 

Dada una consulta C, el trabajo del sistema de recu¬ 
peración de la información es devolver documentos en 
orden descendente de importancia para C. Dado que 
puede haber un gran número de documentos que carez¬ 


can de importancia, los sistemas de recuperación de la 
información suelen devolver únicamente los primeros 
documentos con el grado más elevado de importancia 
estimada y permiten a los usuarios solicitar de manera 
interactiva más documentos. 

22.5.1.2. La importancia cuando se utilizan 
hipervínculos 

Los primeros motores de búsqueda de la Web clasifica¬ 
ban los documentos utilizando sólo medidas de impor¬ 
tancia parecidas a las descritas en el Apartado 22.5.1.1. 
Sin embargo, los investigadores pronto se dieron cuen¬ 
ta de que los documentos Web contienen información 
de la que carecen los documentos de texto sencillo, por 
ejemplo, los hipervínculos. Y, de hecho, la ordenación 
por la importancia de los documentos se ve más afecta¬ 
da por los hipervínculos que apuntan al documento que 
por los hipervínculos que proceden del documento. 

La idea básica de la clasificación de los sitios es hallar 
sitios que sean populares, y clasificar las páginas de esos 
sitios por encima de las páginas de otros sitios. Un sitio 
queda identificado por la parte de la dirección de inter¬ 
net de su URL, como, por ejemplo, www.bell-labs.com 
en la URL http://www.bell-labs.com/topic/books/db-book. 
Cada sitio suele contener varias páginas web. Dado que 
la mayor parte de las búsquedas pretenden hallar infor¬ 
mación de los sitios populares, la clasificación de las 
páginas de los sitios populares por encima de las demás 
suele ser una buena idea. Por ejemplo, el término «goo- 
gle» puede aparecer en gran número de páginas, pero 
el sitio google.com es el sitio más popular de entre los 
sitios con páginas que contienen el término «google». 
Los documentos procedentes de google.com que con¬ 
tengan el término «google» se clasificarán, por tanto, 
como los más importantes para el término «google». 

Esto suscita la pregunta del modo de definir la popu¬ 
laridad de un sitio. Una manera es hallar la cantidad de 
veces que se tiene acceso a ese sitio. Sin embargo, la 
obtención de esa información es imposible sin la coo¬ 
peración del sitio, y no les es factible implementarla a 
los motores de búsqueda web. Una alternativa muy efec¬ 
tiva utiliza los hipervínculos; define p(s), la populari¬ 
dad del sitio 5, como el número de sitios que contienen 
como mínimo una página con un vínculo con el sitio 5. 

Las medidas tradicionales de la importancia de una 
página (que se vieron en el Apartado 22.5.1.2) pueden 
combinarse con la popularidad del sitio que contiene la 
página para obtener una medida global de la importan¬ 
cia de la página. Las páginas con un valor elevado de 
su importancia global se devuelven como respuestas de 
la consulta, como ya se ha visto. 

También hay que tener en cuenta que se ha utiliza¬ 
do la popularidad del sitio como medida de la impor¬ 
tancia de las páginas de ese sitio, no la popularidad de 
cada una de las páginas. Hay, como mínimo, dos razo¬ 
nes para ello. En primer lugar, la mayor parte de los 
sitios sólo contienen páginas a las páginas iniciales de 
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los otros sitios, por lo que parecería que todas las demás 
páginas tienen una popularidad casi nula, cuando en rea¬ 
lidad puede que se tenga acceso bastante frecuente a 
ellas siguiendo los vínculos desde la página inicial. En 
segundo lugar, hay muchos menos sitios que páginas, 
por lo que el cálculo y el empleo de la popularidad de los 
sitios resulta más económico que el cálculo y el empleo 
de la popularidad de las páginas. 

Hay definiciones más refinadas de la popularidad 
de los sitios. Por ejemplo, puede que se considere un 
vínculo desde un sitio popular a otro sitio s una indica¬ 
ción mejor de la popularidad de s que un vínculo con 5 
desde un sitio menos popular 6 . Esta definición de popu¬ 
laridad es, de hecho, circular, ya que la popularidad de 
un sitio queda definida por la popularidad de otros sitios 
y puede que haya ciclos de vínculos entre los sitios. No 
obstante, la popularidad de los sitios puede definirse 
mediante un sistema de ecuaciones lineales simultá¬ 
neas, que pueden resolverse mediante las técnicas de 
tratamiento de matrices. Las ecuaciones lineales se defi¬ 
nen de manera que tienen una solución única y bien defi¬ 
nida. 

El popular motor de búsqueda Web google.com uti¬ 
liza la idea de popularidad de los sitios remitentes en su 
definición de clasificación de las páginas, que es una 
medida de la popularidad de cada página. Este enfoque 
de la clasificación de las páginas ha dado muchos mejo¬ 
res resultados que las técnicas de clasificación utiliza¬ 
das anteriormente, por lo que google.com se ha con¬ 
vertido en un motor de búsqueda muy utilizado en un 
periodo de tiempo bastante breve. 

Hay otro enfoque, en cierto modo parecido, que, 
curiosamente, procede de una teoría de redes sociales 
desarrollada por los sociólogos en los años cincuenta 
del siglo pasado. En el contexto de las redes sociales el 
objetivo era definir el prestigio de las personas. Por 
ejemplo, el presidente de los Estados Unidos tiene un 
elevado prestigio, ya que gran cantidad de gente lo cono¬ 
ce. Si alguien es conocido por varias personas de pres¬ 
tigio, también tendrá un prestigio elevado, aunque no 
sea conocido por un número de personas tan grande. 

La idea anterior se desarrolló hasta una definición de 
nodos y de autoridades que tiene en cuenta la presen¬ 
cia de directorios para enlazar con páginas que contie¬ 
nen información útil. Un nodo es una página que alma¬ 
cena vínculos con muchas páginas; no contiene 
información real sobre ningún asunto, pero apunta a 
páginas que sí que la contienen. Por el contrario, una 
autoridad es una página que contiene información real 
sobre un asunto, aunque puede que no apunten a ella 
muchas páginas. Cada página recibe un valor de pres¬ 
tigio como nodo (prestigio-nodo) y otro valor de pres¬ 
tigio como autoridad (prestigio-autoridad ). Las defini¬ 


ciones de prestigio, como ya se ha visto, son cíclicas y 
vienen dadas por un conjunto de ecuaciones lineales 
simultáneas. Una página obtiene un mayor prestigio- 
nodo si apunta a muchas páginas con un elevado pres¬ 
tigio-autoridad, mientras que una página recibe un ele¬ 
vado prestigio-autoridad si apuntan a ella muchas 
páginas con un elevado prestigio-nodo. Dada una con¬ 
sulta, las páginas con prestigio-autoridad elevado se cla¬ 
sifican por encima de las demás páginas. Véanse las 
notas bibliográficas para hallar referencias que ofrez¬ 
can más detalles. 

22.5.1.3. Recuperación basada en la semejanza 

Algunos sistemas de recuperación de la información per¬ 
miten la recuperación basada en la semejanza. En este 
caso, el usuario puede dar al sistema el documento A y 
pedirle que recupere documentos que sean «semejantes» 
a A. El parecido de un documento con otro puede defi¬ 
nirse, por ejemplo, con base en los términos comunes. 
Un enfoque es hallar k términos de A con los valores más 
elevados de i(d, t) y emplear esos k términos como con¬ 
sulta para hallar la importancia de otros documentos. 
Los términos de la consulta se pesan con i(d, t). 

Si el conjunto de documentos semejantes a A es de 
gran tamaño, puede que el sistema sólo presente al usua¬ 
rio unos cuantos documentos, le permita escoger los 
más destacados e inicie una nueva búsqueda basada en 
el parecido con A y con los documentos seleccionados. 
Es posible que el conjunto de documentos resultante sea 
lo que el usuario pretendía hallar. 

La misma idea se utiliza también para ayudar a los 
usuarios que hallan muchos documentos que parecen 
ser importantes de acuerdo con las palabras clave pero 
que no lo son. En esas situaciones, en lugar de añadir 
más palabras clave a la consulta, puede que se permita 
a los usuarios identificar uno o varios de los documen¬ 
tos devueltos como importantes; el sistema utilizará los 
documentos identificados para hallar otros parecidos. 
Es probable que el conjunto de documentos resultante 
sea lo que el usuario pretendía hallar. 

22.5.1.4. Sinónimos y homónimos 

Considérese el problema de la localización de docu¬ 
mentos sobre el mantenimiento de motocicletas con las 
palabras clave «motocicleta» y «mantenimiento». 
Supóngase que las palabras clave para cada documen¬ 
to sean las palabras del título y los nombres de los auto¬ 
res. El documento titulado Reparación de motocicletas 
no se recuperaría, ya que la palabra «mantenimiento» 
no aparece en el título. 

Se puede resolver el problema haciendo uso de los 
sinónimos. Cada palabra puede tener definido un con- 


6 Esto es parecido, en cierto sentido, a conceder un peso extra al aval 
de productos por gente famosa (como las estrellas de cine), por lo 
que su importancia es discutible. 
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junto de sinónimos, y la aparición de una palabra pue¬ 
de ser sustituida por la disyunción de todos sus sinóni¬ 
mos (incluida la propia palabra). Así, la consulta «moto¬ 
cicleta y reparación» puede sustituirse por «motocicleta 
y (reparación o mantenimiento)». Esta consulta sí halla¬ 
ría el documento deseado. 

Las consultas basadas en las palabras clave también 
se ven afectadas por el problema, el de los homónimos, 
es decir, las palabras con varios significados. Por ejem¬ 
plo, la palabra objeto tiene significados diferentes como 
nombre y como verbo. La palabra tabla puede hacer 
referencia a una pieza de madera o a una tabla relacio- 
nal. Algunos sistemas de consultas por palabras clave 
intentan deshacer la ambigüedad del significado de las 
palabras en los documentos, y cuando un usuario for¬ 
mula una consulta averiguan el significado deseado pre¬ 
guntándoselo. Los documentos devueltos son los que 
utilizan el término con el significado deseado por el 
usuario. Sin embargo, la ruptura de la ambigüedad de 
los significados de las palabras de los documentos no 
resulta una tarea sencilla, por lo que no muchos siste¬ 
mas implementan esta idea. 

De hecho, un riesgo de utilizar los sinónimos para 
ampliar las consultas es que los sinónimos pueden tener 
significados diferentes. Se recuperarán documentos que 
utilizan los sinónimos con un significado implícito alter¬ 
nativo y el usuario se pregunta el motivo de que el sis¬ 
tema considerara que uno de los documentos recupera¬ 
dos era importante, si no contiene ni las palabras clave 
especificadas por el usuario ni las palabras cuyo signi¬ 
ficado implícito en el documento es sinónimo de las 
palabras clave especificadas. Por tanto, es recomenda¬ 
ble comprobar los sinónimos con el usuario antes de 
utilizarlos para ampliar una consulta que éste haya for¬ 
mulado. 

22.5.2. Indexado de documentos 

Una estructura efectiva de índices es importante para el 
procesamiento eficiente de las consultas en los sistemas 
de recuperación de la información. Los documentos que 
contengan las palabras clave especificadas pueden loca¬ 
lizarse de manera efectiva utilizando un índice inver¬ 
tido, que relaciona cada palabra clave K¡ con el con¬ 
junto S¡ de (los identificadores de) los documentos que 
contienen K¡. Para dar soporte a la clasificación de 
importancia basada en la proximidad de las palabras 
clave estos índices pueden proporcionar no sólo los iden¬ 
tificadores de los documentos, sino también una lista de 
las ubicaciones en el documento en las que aparecen las 
palabras clave. 

Dado que esos índices hay que almacenarlos en dis¬ 
co, la organización del índice también intenta minimi¬ 
zar el número de operaciones de E/S para la recupera¬ 
ción del conjunto de (identificadores de) documentos 
que contienen las palabras clave. Así, puede que el sis¬ 
tema intente guardar el conjunto de documentos de cada 
palabra clave en páginas consecutivas del disco. 


La operación y halla los documentos que contienen 
todas las palabras clave de un conjunto especificado 
K l7 K 2 ,K n . La operación y se implementa recupe¬ 
rando primero los conjuntos de identificadores de docu¬ 
mentos Sj, S 2 ,.. •, S n de todos los documentos que con¬ 
tienen las palabras clave respectivas. 

La intersección S { D S 2 fl • ■ • D S n , de los conjuntos 
de documentos da los identificadores de los documen¬ 
tos del conjunto de documentos deseado. La operación 
o da el conjunto de todos los documentos que contie¬ 
nen al menos una de las palabras clave K X ,K 2 ,..., K n . La 
operación o se implementa calculando la unión, Sj U S 2 
U • ■ -U S n , de los conjuntos. La operación no halla los 
documentos que no contienen la palabra clave especi¬ 
ficada K¡. Dado un conjunto de identificadores S, se pue¬ 
den eliminar los documentos que contengan la palabra 
clave especificada K¡ tomando la diferencia S - S¡, don¬ 
de S¡ es el conjunto de identificadores de los documen¬ 
tos que contienen la palabra clave K¡. 

Dado un conjunto de palabras clave de una consul¬ 
ta, muchos sistemas de recuperación de la información 
no insisten en que los documentos recuperados conten¬ 
gan todas las palabras clave (a menos que se utilice de 
manera explícita una operación y). En ese caso, se recu¬ 
peran todos los documentos que contengan como míni¬ 
mo una de las palabras clave (como en la operación o), 
pero se clasifican de acuerdo con su medida de impor¬ 
tancia. 

Para utilizar en la clasificación la frecuencia de los 
términos, la estructura de índices también debe mante¬ 
ner el número de veces que aparecen los términos en 
cada documento. Para reducir este esfuerzo pueden uti¬ 
lizar una representación comprimida con sólo unos 
pocos bits, que aproxima la frecuencia de los términos. 
El índice también debe almacenar la frecuencia de docu¬ 
mentos de cada término (es decir, el número de docu¬ 
mentos en que aparece cada término). 

22.5.3. Medida de la efectividad 
de la recuperación 

Cada palabra clave puede estar incluida en gran núme¬ 
ro de documentos; por tanto, una representación com¬ 
pacta resulta fundamental para mantener bajas las nece¬ 
sidades de espacio del índice. Así, los conjuntos de 
documentos de cada palabra clave se conservan en for¬ 
ma comprimida. Para ahorrar espacio de almacena¬ 
miento a veces se almacena el índice de modo que la 
recuperación es aproximada; puede que no se recupe¬ 
ren unos pocos documentos de importancia (lo que se 
denomina un rechazo falso o un falso negativo), o pue¬ 
de que se recuperen unos pocos documentos sin impor¬ 
tancia (lo que se denomina un falso positivo). Una bue¬ 
na estructura de índice no tiene ningún rechazo falso, 
pero puede que permita algunos falsos positivos; el sis¬ 
tema puede filtrarlos posteriormente mirando las pala¬ 
bras clave que contienen realmente. En el indexado de 
Webs los falsos positivos tampoco son deseables, ya 
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que puede que el documento real no sea accesible rápi¬ 
damente para su filtrado. 

Se utilizan dos métricas para medir la calidad con que 
los sistemas de recuperación de la información pueden 
contestar las consultas. La primera, la precisión, mide el 
porcentaje de los documentos recuperados que son ver¬ 
daderamente importantes para la consulta. La segunda, 
la recuperación, mide el porcentaje de los documentos 
importantes para la consulta que se han recuperado. Lo 
ideal sería que ambas fueran del ciento por ciento. 

La precisión y la recuperación también son medidas 
importantes para la comprensión de la calidad de una 
determinada estrategia de clasificación de los docu¬ 
mentos. Las estrategias de clasificación pueden dar lugar 
a falsos negativos y en falsos positivos, pero en un sen¬ 
tido más sutil. 

• Pueden producirse falsos negativos al clasificar 
los documentos porque los documentos impor¬ 
tantes obtengan clasificaciones bajas; si se extra¬ 
jeran todos los documentos hasta incluir los que 
tienen clasificaciones muy bajas, habría muy pocos 
falsos negativos. Sin embargo, los usuarios rara 
vez miran más allá de las primeras decenas de 
documentos devueltos y, por tanto, puede que 
pasen por alto documentos importantes porque no 
estén clasificados entre los primeros. Lo que sea 
exactamente un falso negativo depende del núme¬ 
ro de documentos que se examinen. 

Por tanto, en lugar de tener un solo número 
como medida de la recuperación, se puede medir 
la recuperación como una función del número de 
documentos extraídos. 

• Pueden producirse falsos positivos porque docu¬ 
mentos sin importancia obtengan clasificaciones 
más elevadas que algunos documentos importan¬ 
tes. Esto también depende del número de docu¬ 
mentos que se examinen. Una posibilidad es medir 
la precisión como función del número de docu¬ 
mentos extraídos. 

Una opción mejor y más intuitiva para la medida de 
la precisión es medirla como función de la recupera¬ 
ción. Con esta medida combinada, tanto la precisión 
como la recuperación pueden calcularse en función del 
número de documentos, si hiciera falta. 

Por ejemplo, se puede decir que con una recupera¬ 
ción del 50 por ciento la precisión era del 75 por cien¬ 
to, mientras que con una recuperación del 75 por cien¬ 
to la precisión cayó hasta el 60 por ciento. En general, 
se puede dibujar una gráfica que relacione la precisión 
con la recuperación. Estas medidas pueden calcularse 
para las diferentes consultas y promediarse para un con¬ 
junto de consultas en una prueba de homologación de 
la calidad de las consultas. 

Otro problema más con la medida de la precisión y 
de la recuperación consiste en el modo de definir los 
documentos que son realmente importantes y los que 


no lo son. De hecho, decidir si un documento es impor¬ 
tante o no lo es exige la comprensión del lenguaje natu¬ 
ral y de las pretensiones de la consulta. Los investiga¬ 
dores, por tanto, han creado conjuntos de documentos 
y de consultas y han marcado manualmente los docu¬ 
mentos como importantes o no importantes para las con¬ 
sultas. Se pueden ejecutar diferentes sistemas de clasi¬ 
ficación con estos conjuntos de documentos para medir 
la precisión y la recuperación medias de varias consul¬ 
tas. 

22.5.4. Motores de búsqueda web 

Los programas denominados web crawlers (batidores 
web) son programas que localizan y reúnen informa¬ 
ción de la Web. Siguen de manera recursiva los hiper- 
vínculos presentes en los documentos conocidos para 
hallar otros documentos. Los batidores recuperan los 
documentos y añaden la información hallada en ellos a 
índices combinados; generalmente, los documentos no 
se almacenan, aunque algunos motores de búsqueda 
guardan en la caché una copia del documento para dar 
a los clientes un acceso más rápido a los documentos. 
Dado que el número de documentos de la Web es muy 
grande, no es posible recorrer toda la Web en un perio¬ 
do corto de tiempo; y, de hecho, todos los motores de 
búsqueda cubren únicamente algunas partes de la Web, 
no toda ella, y sus batidores pueden tardar semanas o 
meses en realizar una sola batida de todas las páginas 
que abarcan. Suele haber muchos procesos ejecutándo¬ 
se en varias máquinas, implicadas en las batidas. Una 
base de datos almacena un conjunto de vínculos (o de 
sitios) que hay que batir; asigna los vínculos que par¬ 
ten de este conjunto a cada proceso batidor. Los víncu¬ 
los nuevos hallados durante cada batida se añaden a la 
base de datos, y puede que se batan posteriormente si 
no se baten de manera inmediata. Las páginas halladas 
durante cada batida también se pasan al sistema de inde- 
xado, que puede que se ejecute en una máquina dife¬ 
rente. Hay que volver a extraer las páginas (es decir, 
volver a batir los vínculos) de manera periódica para 
obtener información actualizada y descartar los sitios 
que ya no existan, de modo que la información del índi¬ 
ce de búsqueda se mantenga razonablemente actuali¬ 
zada. 

El propio sistema de indexado se ejecuta en parale¬ 
lo en varias máquinas. No resulta una buena idea aña¬ 
dir las páginas al mismo índice que se utiliza para las 
consultas, ya que eso exige el control de la concurren¬ 
cia en el índice y afecta al rendimiento de las consultas 
y de las actualizaciones. En lugar de eso, se utiliza una 
copia del índice para responder a las consultas mientras 
se actualiza otra copia con las páginas recién batidas. 
A intervalos periódicos se intercambian las copias y se 
actualiza la más antigua mientras la copia nueva se uti¬ 
liza para las consultas. 

Para soportar tasas de consultas muy elevadas se pue¬ 
den mantener los índices en la memoria principal y, si 
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hay varias máquinas, el sistema encamina de manera 
selectiva las consultas a las máquinas para equilibrar la 
carga de trabajo entre ellas. 

22.5.5. Directorios 

El usuario típico de una biblioteca puede utilizar un catá¬ 
logo para hallar el libro que busca. Cuando recupera el 
libro del estante, no obstante, es probable que hojee 
otros libros que se hallen cerca. Las bibliotecas organi¬ 
zan los libros de modo que los títulos relacionados se 
guarden cerca unos de otros. Por tanto, puede que un 
libro que esté físicamente cerca del libro deseado tam¬ 
bién sea interesante, lo que hace interesante para los 
usuarios hojear esos libros. 

Para guardar cerca unos de otros los libros relacio¬ 
nados, las bibliotecas utilizan una jerarquía de clasi¬ 
ficación. Los libros de ciencias se clasifican juntos. Den¬ 
tro de este conjunto de libros hay una clasificación más 
fina, que organiza por un lado los libros de informáti¬ 
ca, por otro los de matemáticas, etcétera. Dado que hay 
una relación entre las matemáticas y la informática, hay 
conjuntos importantes de libros que se guardan física¬ 
mente cerca. En otro nivel diferente de la jerarquía de 
la clasificación, los libros de informática se dividen en 
subáreas, como los sistemas operativos, los lenguajes y 
los algoritmos. La Ligura 22.10 muestra una jerarquía 
de clasificación que las bibliotecas pueden emplear. 
Como los libros sólo se pueden guardar en un sitio, cada 
libro de una biblioteca se clasifica exactamente en un 
punto de la jerarquía de clasificación. 

En los sistemas de recuperación de la información 
no hace falta almacenar cerca los documentos relacio¬ 
nados. No obstante, estos sistemas necesitan organizar 
lógicamente los documentos para permitir su explora¬ 
ción. Por tanto, estos sistemas pueden utilizar una jerar¬ 


quía de clasificación parecida a la que utilizan las biblio¬ 
tecas y, cuando muestra un documento concreto, tam¬ 
bién puede mostrar una breve descripción de los docu¬ 
mentos que se hallan cercanos en la jerarquía. 

En los sistemas de recuperación de la información 
no hace falta guardar cada documento en un solo pun¬ 
to de la jerarquía. Los documentos que traten de mate¬ 
máticas para informáticos pueden clasificarse en mate¬ 
máticas y en informática. Todo lo que se guarda en cada 
punto es un identificador del documento (es decir, un 
puntero hacia el documento), y resulta sencillo ex¬ 
traer el contenido del documento empleando el identi¬ 
ficador. 

Como consecuencia de esa flexibilidad, no sólo se 
puede clasificar cada documento en dos posiciones, sino 
que también puede aparecer una subárea de la jerarquía 
de la clasificación en dos áreas diferentes. La clase de 
documento «algoritmo de grafos» puede aparecer tan¬ 
to en matemáticas como en informática. Por tanto, la 
jerarquía de clasificación es ahora un grafo acíclico diri¬ 
gido (GAD), como puede verse en la Ligura 22.11. Los 
documentos de algoritmos de grafos pueden aparecer 
en una sola posición del GAD, pero puede llegarse a 
ellos por varios caminos. 

Un directorio no es más que una estructura de cla¬ 
sificación GAD. Cada hoja del directorio almacena los 
vínculos con documentos del tema representado por 
la hoja. Los nodos internos también pueden contener 
vínculos, por ejemplo, con documentos que no se pue¬ 
den clasificar en ninguno de los nodos hijo. 

Para hallar información sobre un asunto los usua¬ 
rios empiezan en la raíz del directorio y siguen los cami¬ 
nos por el GAD hasta alcanzar el nodo que representa 
el asunto deseado. Mientras avanzan por el directorio 
los usuarios no sólo pueden hallar documentos sobre 
el asunto en el que están interesados, sino que también 
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pueden hallar documentos relacionados y clases rela¬ 
cionadas en la jerarquía de clasificación. Los usuarios 
pueden conseguir información nueva explorando los 
documentos (o las subclases) de las clases relaciona¬ 
das. 

La organización de la enorme cantidad de informa¬ 
ción disponible en la Web en una estructura de directo¬ 
rio es una tarea aterradora. 

• El primer problema es la determinación de cuál 
debe ser exactamente la jerarquía del directorio. 

• El segundo problema es, dado un documento, deci¬ 
dir los nodos del directorio que son categorías 
importantes para el documento. 


Para afrontar el primer problema, los portales como 
Yahoo tienen equipos de «bibliotecarios de Internet» 
que sugieren la jerarquía de la clasificación y la refinan 
de manera continua. El Proyecto de directorio abierto 
(Open Directory Project ) es un gran esfuerzo coopera¬ 
tivo con diferentes voluntarios que son responsables de 
organizar diferentes ramas del directorio. 

El segundo problema también pueden afrontarlo 
manualmente los bibliotecarios, o puede que los conser¬ 
vadores del sitio web sean responsables de decidir el lugar 
de la jerarquía en que deben ubicarse sus sitios. También 
hay técnicas para decidir de manera automática la ubica¬ 
ción de los documentos de acuerdo con el cálculo de su 
parecido con documentos que ya se hayan clasificado. 


22.6. RESUMEN 


• Los sistemas de ayuda a la toma de decisiones anali¬ 
zan en línea los datos recogidos por los sistemas de 
procesamiento de transacciones para ayudar a los usua¬ 
rios a adoptar decisiones de negocios. Dado que hoy 
en día la mayor parte de las organizaciones están inten¬ 
samente informatizadas, se dispone de una enorme 
cantidad de información para la ayuda a la toma de 
decisiones. Los sistemas de ayuda a la toma de deci¬ 
siones se presentan en varios formatos, incluidos los 
sistemas OLAP y los sistemas de recopilación de datos. 

• Las herramientas de procesamiento analítico en línea 
(online analytical processing, OLAP) ayudan a los 
analistas a ver los datos resumidos de diferentes mane¬ 
ras, de manera que puedan obtener una perspectiva 
del funcionamiento de la organización. 


— Las herramientas OLAP trabajan con datos mul- 
tidimensionales, caracterizados por los atributos 
de dimensiones y por los atributos de medida. 

— Los cubos de datos consisten en datos multidi- 
mensionales resumidos de diferentes maneras. El 
cálculo previo de los cubos ayuda a acelerar las 
consultas de resúmenes de datos. 

— El formato de las tabulaciones cruzadas permite 
que los usuarios vean simultáneamente dos dimen¬ 
siones de los datos multidimensionales, junto con 
resúmenes de los datos. 

— La concreción, la abstracción y los cortes de los 
cubos de datos son algunas de las operaciones que 
los usuarios llevan a cabo con las herramientas 
OLAP. 
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• El componente OLAP de la norma SQL: 1999 pro¬ 
porciona gran variedad de funcionalidades nuevas 
para el análisis de los datos, incluidas nuevas funcio¬ 
nes de agregación, operaciones con cubos y de abs¬ 
tracción, funciones de clasificación, funciones para la 
creación de ventanas, que soportan la elaboración de 
resúmenes en ventanas móviles, y la realización de 
particiones, con la creación de ventanas y la clasifi¬ 
cación aplicadas dentro de cada partición. 

• La recuperación de datos es el proceso de análisis 
semiautomático de bases de datos de gran tamaño para 
hallar estructuras útiles. Hay gran número de aplica¬ 
ciones de recopilación de datos, como la predicción 
de valores con base en los ejemplos ya pasados, la 
búsqueda de asociaciones entre las compras y la agru¬ 
pación automática de personas y películas. 

• La clasificación trata de la predicción de la clase de 
los ejemplos de prueba utilizando los atributos de los 
ejemplos de prueba con base en los atributos de los 
ejemplos de formación y en la clase real de los ejem¬ 
plos de formación. La clasificación puede utilizarse, 
por ejemplo, para predecir el valor de crédito de los 
nuevos solicitantes o para predecir el rendimiento de 
los estudiantes que solicitan el ingreso en una uni¬ 
versidad. 

Hay varios tipos de clasificadores, como los 

— Clasificadores de árboles de decisión. Estos llevan 
a cabo la clasificación creando un árbol basado en 
los ejemplos de formación con hojas que tienen las 
etiquetas de las clases. Se recorre el árbol para cada 
ejemplo de prueba hasta hallar una hoja y la clase 
de esa hoja es la clase predicha. 

— Se dispone de varias técnicas para crear árboles de 
decisión, la mayor parte de ellas basadas en heurís¬ 
tica codiciosa. 

• Los clasificadores bayesianos son más sencillos de 
crear que los clasificadores de árboles de decisión y 
funcionan mejor en caso de que haya valores de los 
atributos que falten o que sean nulos. 

• Las reglas de asociación identifican los elementos 
que aparecen juntos con frecuencia, por ejemplo, los 
artículos que el mismo cliente suele comprar. Las 
correlaciones buscan las desviaciones respecto de los 
niveles de asociación esperados. 


• Otros tipos de recopilación de datos son el agrupamiento, 
la recopilación de texto y la visualización de datos. 

• Los almacenes de datos ayudan a reunir y archivar los 
datos operativos importantes. Los almacenes de datos 
se utilizan para la ayuda a la toma de decisiones y para 
el análisis de datos históricos, por ejemplo, para pre¬ 
decir tendencias. La limpieza de los datos de los orí¬ 
genes de datos de entrada suele ser una tarea impor¬ 
tante en el almacenaje de datos. Los esquemas de los 
almacenes de datos suelen ser multidimensionales e 
implican una o pocas tablas de hechos muy grandes y 
varias tablas de dimensiones mucho más pequeñas. 

• Los sistemas de recuperación de la información se 
utilizan para almacenar y consultar los datos de tex¬ 
to como los documentos. Utilizan un modelo de datos 
más sencillo que el de los sistemas de bases de datos, 
pero ofrecen posibilidades de búsqueda más potentes 
dentro de ese modelo restringido. 

Las consultas intentan localizar los documentos de 
interés especificando, por ejemplo, conjuntos de pala¬ 
bras clave. La consulta que el usuario tiene en men¬ 
te no suele poder formularse de manera precisa; por 
tanto, los sistemas de recuperación de la información 
ordenan las respuestas con base en su importancia 
potencial. 

• La clasificación por importancia hace uso de varios ti¬ 
pos de información como: 

— Lrecuencia de los términos: la importancia de cada 
término para cada documento. 

— Lrecuencia inversa de los documentos. 

— Popularidad del sitio. La clasificación de las pági¬ 
nas y la clasificación del nodo o de la autoridad son 
dos maneras de asignar importancia a los sitios de 
acuerdo con los vínculos con cada sitio. 

• La semejanza de los documentos se utiliza para recu¬ 
perar documentos parecidos a un documento de ejem¬ 
plo. Los sinónimos y los homónimos complican la 
tarea de la recuperación de la información. 

• La precisión y la recuperación son dos medidas de la 
efectividad de los sistemas de recuperación de la infor¬ 
mación. 

• Las estmcturas de directorio se utilizan para clasifi¬ 
car los documentos con otros documentos parecidos. 


TÉRMINOS DE REPASO 


• Agregación ampliada 

— Correlación 
— Desviación estándar 
— Regresión 
— Varianza 


• Agrupamiento 

— Agrupamiento aglomerativo 
— Agrupamiento divisivo 
— Agrupamiento jerárquico 

• Almacenamiento de datos 
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— Arquitectura dirigida por el destino 

— Arquitectura dirigida por el origen 

— Limpieza de datos 

- Domiciliación 

- Mezcla-purga 

— Recogida de datos 
Análisis estadístico 
Asociaciones 
Batidores web 
Búsqueda por palabras clave 
Clasificación 

— Datos de formación 

— Datos de prueba 
Clasificación por importancia 

— Frecuencia inversa de los documentos 

— Frecuencia de los términos 

— Importancia 

— Proximidad 

Clasificadores de árboles de decisión 

— Atributo categórico 

— Atributo de partición 

— Atributo con valores continuos 

— Condición de partición 

— Contenido de la información 

— División binaria 

— División múltiple 

— Exceso de ajuste 

— Ganancia de información 

— Pureza 

- Medida de la entropía 

- Medida de Gini 

— Tasa de ganancia de la información 
Clasificadores bayesianos 

— Clasificadores bayesianos ingenuos 

— Teorema de Bayes 
Creación de ventanas 
Cubo de datos 

Datos multidimensionales 

— Atributos de dimensiones 

— Atributos de medida 
Directorios 

Esquemas de almacenamiento 

— Esquema en estrella 

— Tablas de dimensiones 

— Tabla de hechos 
Falso negativo 


• Falso positivo 

• Funciones de clasificación 

— Clasificación 

— Clasificación densa 

— División mediante 

• Homónimos 

• Importancia cuando se utilizan hipervínculos 

— Clasificación nodo/autoridad 

— Clasificación de las páginas 

— Popularidad de un sitio 

• índice invertido 

• Jerarquía de clasificación 

• OLAP híbrido (HOLAP) 

• OLAP multidimensional (MOLAP) 

• OLAP relacional (ROLAP) 

• Otros tipos de asociaciones 

• Palabras de parada 

• Precisión 

• Predicción 

• Procesamiento analítico en línea (online analytical 
Processing, OLAP) 

— Abstracción y concreción 

— Cortes de cubos 

— Pivotaje 

• Rechazo falso 

• Recopilación de datos 

• Recopilación de texto 

• Recuperación 

• Recuperación basada en la semejanza 

• Recuperación de texto completo 

• Reglas de asociación 

— Confianza 

— Conjuntos de elementos de gran tamaño 

— Población 

— Soporte 

• Regresión 

— Ajuste de curvas 

— Regresión lineal 

• Sinónimos 

• Sistemas de ayuda a la toma de decisiones 

• Sistemas de recuperación de la información 

• Tabulaciones cruzadas 

• Término 

• Visualización de datos 
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EJERCICIOS 


22.1. Para cada una de las funciones de agregación de SQL 
sum, count, min y max, muéstrese el modo de calcu¬ 
lar el valor agregado para el conjunto múltiple Sj U S 2 , 
dados los valores agregados para los conjuntos múlti¬ 
ples Sj y S 2 . 

Con base en lo anterior hay que dar las expresio¬ 
nes para calcular los valores agregados con agrupa- 
miento en para un subconjunto S de los atributos de 
la relación r(A,B,C,D,E), dados los valores agregados 
para agrupamiento de los atributos T 2 Sj para las 
siguientes funciones de agregación: 

a. sum, count, min y max 

b. avg 

c. Desviación estándar 

22.2. Muéstrese el modo de expresar group by cúbela, b, 
c, d) utilizando rollup: la respuesta sólo debe tener 
una cláusula group by. 

22.3. Dese un ejemplo de un par de agrupamientos que no 
puedan expresarse utilizando una sola cláusula group 
by con cube y rollup. 

22.4. Dada la relación E(estudiante, asignatura, notas), 
escríbase una consulta para hallar los n mejores estu¬ 
diantes por sus notas totales, utilizando la clasifica¬ 
ción. 

22.5. Dada la relación r(a, b, d, d), muéstrese el modo de 
utilizar las características ampliadas de SQL para gene¬ 
rar un histograma de d frente a a, dividiendo a en vein¬ 
te particiones de igual tamaño (es decir, que cada par¬ 
tición contiene el 5 por ciento de las tupias de r, 
ordenadas según a). 

22.6. Escríbase una consulta para hallar saldos acumulati¬ 
vos, equivalente a la mostrada en el Apartado 22.2.5, 
pero sin utilizar las estructuras ampliadas para la 
creación de ventanas de SQL. 

22.7. Considérese el atributo saldo de la relación cuenta. 
Escríbase una consulta en SQL para calcular un his¬ 
tograma de los valores de saldo, dividiendo el rango 
desde cero hasta el máximo saldo de una cuenta pre¬ 
sente, en tres rangos iguales. 

22.8. Considérese la relación ventas del Apartado 22.2. 
Escríbase una consulta en SQL para calcular la ope¬ 
ración cubo para la relación, dada la relación de la 
Figura 22.2. No hay que utilizar la estructura with 
cube. 

22.9. Créese un clasificador de árboles de decisión con divi¬ 
siones binarias en cada nodo utilizando las tupias de 
la relación r(A,B,C) que se muestra más abajo como 
datos de formación; el atributo C denota la clase. 
Muéstrese el árbol final y, con cada nodo, muéstrese 
la mejor división para cada atributo junto con su valor 
de ganancia de la información. 

(1, 2, a), (2, 1, a), (2, 5, b), (3, 3, h), (3, 6, tí), 
(4,5 ,b), (5,5 ,c), (6, 3, b), (6, 7, c) 


22.10. Supóngase que hay dos reglas de clasificación, una 
que dice que la gente con sueldos entre 10.000 € y 
20.000 € tienen una calificación de crédito de buena, 
y otra que dice que la gente con sueldos entre 20.000 
€ y 30.000 € tienen una calificación de crédito de 
buena. Hay que indicar las condiciones para las que 
se pueden sustituir las reglas, sin pérdida de infor¬ 
mación, por una sola regla que diga que las personas 
con sueldos entre 10.000 € y 30.000 € tienen una 
calificación de crédito de buena. 

22.11. Supóngase que la mitad de las transacciones de una 
tienda de ropa adquieren vaqueros y un tercio de las 
transacciones de la tienda adquieren camisetas. Supón¬ 
gase también que la mitad de las transacciones que 
adquieren vaqueros también adquieren camisetas. Hay 
que anotar todas las reglas de asociación (no trivia¬ 
les) que se puedan deducir de esta información, dan¬ 
do el soporte y la confianza de cada regla. 

22.12. Considérese el problema de hallar conjuntos de artícu¬ 
los de gran tamaño. 

a. Descríbase el modo de hallar el soporte de un con¬ 
junto dado de conjuntos de elementos mediante una 
sola exploración de los datos. Supóngase que los 
conjuntos de artículos y la información asociada, 
como los recuentos, caben en la memoria. 

b. Supóngase que un conjunto de artículos tiene un 
soporte menor que j. Muéstrese que ningún super- 
conjunto de este conjunto de artículos puede tener 
un soporte mayor o igual que j. 

22.13. Descríbanse las ventajas y los inconvenientes de una 
arquitectura dirigida por el origen para la recolección 
de datos en los almacenes de datos en comparación 
con una arquitectura dirigida por el destino. 

22.14. Considérese el esquema dibujado en la Figura 22.9. 
Dada una consulta de SQL: 1999 para resumir las cifras 
de ventas y los precios por tienda y por fecha, junto 
con las jerarquías para tienda y fecha. 

22.15. Calcúlese la importancia (mediante las definiciones 
adecuadas de la frecuencia de los términos y de la fre¬ 
cuencia inversa de los documentos) de cada una de 
las preguntas de este capítulo para la consulta «rela¬ 
ción SQL». 

22.16. Expliqúese la diferencia entre un falso positivo y un 
rechazo falso. Si es fundamental que las consultas de 
recuperación de la información no pierdan ninguna 
información importante, explicar si es aceptable tener 
falsos positivos o rechazos falsos. Explicar el motivo. 

22.17. Supóngase que se desea hallar documentos que con¬ 
tengan como mínimo k palabras clave de un conjun¬ 
to dado de n. Supóngase también que se dispone de 
un índice de palabras clave que da una lista (ordena¬ 
da) de identificadores de documentos que contienen 
una palabra clave dada. Dese un algoritmo eficiente 
para hallar el conjunto de documentos deseado. 
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NOTAS BIBLIOGRÁFICAS 


Gray et al. [1995] y Gray et al. [1997] describen el ope¬ 
rador cubo de datos. Los algoritmos eficientes para cal¬ 
cular cubos de datos se describen en Agarwal et al. 
[1996], Harinarayan et al. [1996] y Ross y Srivastava 
[1997]. Las descripciones del soporte ampliado de la 
agregación en SQL: 1999 puede hallarse en los manua¬ 
les de los productos de sistemas de bases de datos como 
Oracle y DB2 de IBM. Las definiciones de las funcio¬ 
nes estadísticas pueden hallarse en los libros de texto nor¬ 
males de estadística como Bulmer [1979] y Ross [1999]. 

Witten y Frank [1999] y Han y Kamber [2000] pro¬ 
porcionan cobertura del nivel de los libros de texto de 
la recopilación de datos. Mitchell [1997] es un libro de 
texto clásico sobre aprendizaje de las máquinas y trata 
con detalle las técnicas de clasificación. Fayyad et al. 
[1995] presentan un extenso conjunto de artículos sobre 
la búsqueda de información y la recopilación de datos. 
Kohavi y Provost [2001] presentan un conjunto de ar¬ 
tículos sobre aplicaciones de la recopilación de datos 
para el comercio electrónico. 

Agrawal et al. [1993] proporcionan una primera intro¬ 
ducción a la recopilación de datos en las bases de datos. 
En Agrawal et al. [1992] y Shafer et al. [1996] se des¬ 
criben algoritmos para el cálculo de clasificadores con 
conjuntos de formación de gran tamaño; el algoritmo de 
creación del árbol de decisión descrito en este capítulo 
se basa en el algoritmo SPRINT de Shafer et al. [1996]. 
Agrawal y Srikant [1994] fue uno de los primeros tex¬ 
tos sobre la recopilación de reglas de asociación. Los 
algoritmos para la recopilación de diferentes formas de 
las reglas de asociación se describen en Srikant y Agra¬ 
wal [1996a] y en Srikant y Agrawal [1996b]. Chakra- 
barti et al. [1998] describen las técnicas para la recopi¬ 
lación de estructuras temporales sorprendentes. 

Durante mucho tiempo se ha estudiado el agrupa- 
miento en el área de la estadística, y Jain y Dubes [1988] 
proporcionan cobertura del agrupamiento del nivel de 
los libros de texto. Ng y Han [1994] describen las téc¬ 
nicas del agrupamiento espacial. Las técnicas de agru¬ 
pamiento para conjuntos de datos de gran tamaño se 
describen en Zhang et al. [1996]. Breese et al. [1998] 


proporcionan un análisis empírico de diferentes algo¬ 
ritmos para el filtrado cooperativo. Las técnicas para el 
filtrado cooperativo de los artículos de noticias se des¬ 
criben en Konstan et al. [1997]. 

Chakrabarti [2000] proporciona una recopilación de 
técnicas de recopilación de hipertexto como la clasifi¬ 
cación y el agrupamiento de hipertexto. Chakrabarti 
[1999] proporciona una recopilación de búsqueda de 
recursos web. Las técnicas para la integración de cubos 
de datos con la recopilación de datos se describen en 
Sarawagi [2000]. 

Poe [1995] y Mattison [1996] proporcionan cober¬ 
tura de los almacenes de datos del nivel de los libros de 
texto. Zhuge et al. [1995] describen el mantenimiento 
de las vistas en entornos de almacenes de datos. 

Witten et al. [1999], Grossman y Frieder [1998] y 
Baeza-Yates y Ribeiro-Neto [1999] proporcionan des¬ 
cripciones de libro de texto de la recuperación de la 
información. El indexado de los documentos se trata 
con detalle en Witten et al. [1999]. Jones y Willet [1997] 
es un conjunto de artículos sobre recuperación de la 
información. Saltón [1989] es uno de los primeros libros 
de texto sobre sistemas de recuperación de la informa¬ 
ción. El índice TREC (trec.nist.gov) es una prueba para 
la medida de la efectividad de la recuperación. 

Brin y Page [1998] describen la anatomía del motor 
de búsqueda Google, incluida la técnica PageRank, 
mientras que una técnica de clasificación de nodos y de 
autoridades denominada HITS se describe en Kleinberg 
[1999]. Bharat y Henzinger [1998] presentan una mejo¬ 
ra de la técnica de clasificación HITS. Un punto que 
merece la pena destacar es que el PageRank de una pági¬ 
na se calcula independientemente de cualquier consul¬ 
ta, y que como consecuencia las páginas con clasifica¬ 
ción elevada que resulta que sólo contienen algunas 
palabras clave sin importancia figuran entre las prime¬ 
ras respuestas a las consultas sobre esas palabras clave 
sin importancia. Por el contrario, el algoritmo HITS tie¬ 
ne en consideración las palabras clave de la consulta al 
calcular el prestigio, pero tiene un coste más elevado 
para la respuesta de las consultas. 


HERRAMIENTAS 


Se dispone de gran variedad de herramientas para cada 
una de las aplicaciones que se han estudiado en este 
capítulo. La mayor parte de los fabricantes de bases de 
datos proporcionan herramientas OLAP como parte de 
sus sistemas de bases de datos, o como aplicaciones 
complementarias. Entre ellas están las herramientas 
OLAP de Microsoft Corp., Oracle Express e Informix 
Metacube. La herramienta OLAP Arbor Essbase pro¬ 


cede de un fabricante de software independiente. El sitio 
www.databeacon.com proporciona una demostración 
en línea de las herramientas OLAP para balizamiento 
de datos para empleo en la web y en orígenes de datos 
de archivos de texto. Muchas empresas también ofre¬ 
cen herramientas de análisis especializadas para apli¬ 
caciones específicas, como la gestión de las relaciones 
con los clientes. 
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También hay una gran variedad de herramientas de 
recopilación de datos de propósito general que incluyen 
las herramientas de recopilación del SAS Institute, IBM 
intelligent Miner y SG1 Mineset. Se necesita una gran 
experiencia para aplicar las herramientas de recopilación 
de datos de propósito general para aplicaciones especí¬ 
ficas. En consecuencia, se han desarrollado gran núme¬ 
ro de herramientas de recopilación para abordar aplica¬ 
ciones especializadas. El sitio web www.kdnuggets.com 
proporciona un amplio directorio de software de recopi¬ 
lación de datos, soluciones, publicaciones, etcétera. 


Los principales fabricantes de bases de datos tam¬ 
bién ofrecen productos para el almacenamiento de datos 
asociados con sus sistemas de bases de datos. Estos pro¬ 
porcionan funcionalidad de soporte para el modelado, 
la limpieza, la carga y la consulta de datos. El sitio web 
www.dwinfocenter.org proporciona información sobre 
productos de almacenaje de datos. 

Google (www.google.com) es un popular motor de 
búsqueda. Yahoo (www.yahoo.com) y el Open Direc- 
tory Project (dmoz.org) proporcionan jerarquías de cla¬ 
sificación para los sitios web. 
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CAPÍTULO 

TIPOS DE DATOS AUTOMÁTICOS 
Y NUEVAS APLICACIONES 


D urante la mayor parte de la historia de las bases de datos, los tipos de datos almacena¬ 
dos en ellas eran relativamente sencillos, y esto se reflejaba en el soporte bastante limi¬ 
tado de los tipos de datos en versiones anteriores de SQL. En los últimos años, sin 
embargo, ha habido una necesidad creciente de manejar tipos de datos nuevos en las bases de 
datos, como los datos temporales, los datos espaciales y los datos multimedia. 

Otra tendencia importante de la última década ha creado sus propios problemas: el auge de 
la informática móvil, que comenzó con las computadoras portátiles y las agendas de bolsillo y, 
en tiempos más recientes, ha seguido para incluir los teléfonos móviles con computadoras inclui¬ 
das y una gran variedad de computadoras portátiles, que se emplean cada vez más en aplica¬ 
ciones comerciales. 

En este capítulo se estudian varios tipos nuevos de datos y también se estudian los proble¬ 
mas de las bases de datos relacionados con la informática móvil. 



23.1. MOTIVACIÓN 


Antes de abordar a fondo cada uno de los temas se 
resumirá la motivación de cada uno de estos tipos de 
datos y algunos problemas importantes del trabajo con 
ellos. 

• Datos temporales. La mayor parte de los siste¬ 
mas de bases de datos modelan el estado actual 
del mundo, por ejemplo, los clientes actuales, los 
estudiantes actuales y los cursos que se están ofer¬ 
tando. En muchas aplicaciones es muy importan¬ 
te almacenar y recuperar la información sobre 
estados anteriores. La información histórica pue¬ 
de incorporarse de manera manual en el diseño 
del esquema. No obstante, la tarea se simplifica 
mucho con el soporte de los datos temporales por 
la base de datos, lo cual se estudia en el Aparta¬ 
do 23.2. 

• Datos espaciales. Entre los datos espaciales 
están los datos geográficos, como los datos y la 
información asociada a ellos, y los datos de dise¬ 
ño asistido por computadora, como los dise¬ 
ños de circuitos integrados o los diseños de edi¬ 
ficios. Las aplicaciones de datos espaciales en 
un principio almacenaban los datos como archi¬ 
vos de un sistema de archivos, igual que las apli¬ 
caciones de negocios de las primeras generacio¬ 
nes. Pero, a medida que la complejidad y el 
volumen de los datos, y el número de usuarios, 
han aumentado, se han probado insuficientes 
para las necesidades de muchas aplicaciones que 
utilizan datos espaciales los enfoques ad hoc para 


almacenar y recuperar los datos en un sistema 
de archivos. 

Las aplicaciones de datos espaciales necesitan 
los servicios ofrecidos por los sistemas de bases 
de datos, en especial, la posibilidad de almacenar 
y consultar de manera eficiente grandes cantida¬ 
des de datos. Algunas aplicaciones también pue¬ 
den necesitar otras características de las bases de 
datos, como las actualizaciones atómicas de parte 
de los datos almacenados, la durabilidad y el con¬ 
trol de la concurrencia. En el Apartado 23.3 se estu¬ 
dian las ampliaciones de los sistemas de bases de 
datos tradicionales necesarias para que soporten 
los datos espaciales. 

• Datos multimedia. En el Apartado 23.4 se estu¬ 
dian las características necesarias en los siste¬ 
mas de bases de datos que almacenan datos mul¬ 
timedia como los datos de imágenes, de vídeo o 
de audio. La principal característica que dife¬ 
rencia a los datos de vídeo y de audio es que la 
exhibición de éstos exige la recuperación a una 
velocidad predeterminada constante; por tanto, 
esos datos se denominan datos de medios con¬ 
tinuos. 

• Bases de datos móviles. En el Apartado 23.5 se 
estudian los requisitos para las bases de datos de 
la nueva generación de sistemas informáticos por¬ 
tátiles, como las computadoras portátiles y los dis¬ 
positivos informáticos de bolsillo, que se conec¬ 
tan con las estaciones base mediante redes de 
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comunicación digitales inalámbricas. Estas com¬ 
putadoras necesitan poder operar mientras se hallan 
desconectadas de la red, a diferencia de los siste¬ 
mas distribuidos de bases de datos estudiados en 


el Capítulo 19. También tienen una capacidad de 
almacenamiento limitada y, por tanto, necesitan 
técnicas especiales para la administración de la 
memoria. 


23.2. EL TIEMPO EN LAS BASES DE DATOS 


Las bases de datos modelan el estado de algún aspecto 
del mundo real externo a ellas. Generalmente, las bases 
de datos sólo modelan un estado —el estado actual— 
del mundo real, y no almacenan información sobre esta¬ 
dos anteriores excepto, quizás, como registro para la 
auditoría. Cuando se modifica el estado del mundo real, 
se actualiza la base de datos y se pierde la información 
sobre el estado anterior. Sin embargo, en muchas apli¬ 
caciones es importante almacenar y recuperar informa¬ 
ción sobre estados anteriores. Por ejemplo, una base de 
datos sobre pacientes debe almacenar información sobre 
el historial médico de cada paciente. El sistema de con¬ 
trol de una fábrica puede almacenar información sobre 
las lecturas actuales y anteriores de los sensores de la 
fábrica para su análisis. Las bases de datos que alma¬ 
cenan información sobre los estados del mundo real a 
lo largo del tiempo se denominan bases de datos tem¬ 
porales. 

Al considerar el problema del tiempo en los siste¬ 
mas de bases de datos se distingue entre el tiempo medi¬ 
do por el sistema y el tiempo observado en el mundo 
real. El momento válido de un hecho es el conjunto de 
intervalos de tiempo en el que el hecho es cierto en el 
mundo real. El momento de transacción de un hecho 
es el intervalo de tiempo en el que el hecho es actual en 
el sistema de bases de datos. Este segundo tiempo se 
basa en el orden de secuenciación de las transacciones 
y el sistema lo genera de manera automática. Hay que 
tener en cuenta que los intervalos de tiempo válidos, 
que son un concepto del tiempo real, no pueden gene¬ 
rarse de manera automática y se le deben proporcionar 
al sistema. 


Una relación temporal es una relación en la que 
cada tupia tiene un tiempo asociado en que es verdade¬ 
ra; el tiempo puede ser tiempo válido o tiempo de tran¬ 
sacción. Por supuesto, tanto el momento válido como 
el momento de transacción pueden almacenarse, en cuyo 
caso la relación se denomina relación bitemporal. La 
Figura 23.1 muestra un ejemplo de relación temporal. 
Para simplificar la representación cada tupia tiene aso¬ 
ciado un único intervalo temporal; así, cada tupia se 
representa una vez para cada intervalo de tiempo dis¬ 
junto en que es cierta. Los intervalos se muestran aquí 
como pares de atributos de y a; una implementación real 
tendría un tipo estmcturado, acaso denominado Inter¬ 
valo , que contuviera los dos campos. Obsérvese que 
algunas de la tupias tienen un asterisco en la columna 
temporal a\ esos asteriscos indican que la tupia es ver¬ 
dadera hasta que se modifique el valor de la columna 
temporal a\ así, la tupia es cierta en el momento actual. 
Aunque los tiempos se muestran en forma textual, se 
almacenan internamente de una manera más compacta, 
como el número de segundos desde algún momento de 
una fecha fija (como las 12:00 am, 1 de enero, 1900) 
que puede volver a traducirse a la forma textual normal. 

23.2.1. Especificación del tiempo en SQL 

El estándar SQL define los tipos date, time y times- 
tamp. El tipo date contiene cuatro cifras para los años 
(1 - 9999), dos para los meses (1 - 12) y dos más para 
los días (1 - 31). El tipo time contiene dos cifras para 
la hora, dos para los minutos y otras dos para los segun¬ 
dos, además de cifras decimales opcionales. El campo 


Número-cuenta 

Nombre-oficina 

Saldo 

De 

A 

C-101 

Centro 

500 

9:00 

1/1/1999 

11:30 

24/1/1999 

C-101 

Centro 

100 

11:30 

24/1/1999 

* 


C-215 

Becerril 

700 

15:30 

2/6/2000 

10:00 

8/8/2000 

C-215 

Becerril 

900 

10:00 

8/8/2000 

8:00 

5/9/2000 

C-215 

Becerril 

700 

8:00 

5/9/2000 

* 


C-217 

Galapagar 

750 

11:00 

5/7/1999 

16:00 

1/5/2000 


FIGURA 23.1. La relación temporal cuenta. 
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de los segundos puede superar el valor de sesenta para 
tener en cuenta los segundos extra que se añaden algu¬ 
nos años para corregir las pequeñas variaciones de velo¬ 
cidad en la rotación de la Tierra. El tipo timestamp con¬ 
tiene los campos de date y de time con seis cifras 
decimales para el campo de los segundos. 

Como las diferentes partes del mundo tienen horas 
locales diferentes suele darse la necesidad de especifi¬ 
car la zona horaria junto con la hora. La hora univer¬ 
sal coordinada (Universel Temps Coordoné, UTC) 
es un punto estándar de referencia para la especifica¬ 
ción de la hora y las horas locales se definen como dife¬ 
rencias respecto a UTC. (La abreviatura estándar es 
UTC, en lugar de UCT, ya que es una abreviatura de 
«tiempo universal coordinado (Universal Coordinated 
Time)» escrito en francés como universel temps coor- 
donné.) SQL también soporta dos tipos, time with time 
zone y timestamp with time zone, que especifican la 
hora como la hora local más la diferencia de la hora 
local respecto de UTC. Por ejemplo, la hora podría 
expresarse en términos de la hora estándar del Este de 
EE.UU. (U.S. Eastern Standard Time), con una dife¬ 
rencia de -6:00, ya que la hora estándar del Este de 
EE.UU. va retrasada seis horas respecto de UTC. 

SQL soporta un tipo denominado ¡nterval, que per¬ 
mite hacer referencia a un periodo de tiempo como pue¬ 
de ser «1 día» o «2 días y 5 horas», sin especificar la 
hora concreta en que comienza el periodo. Este con¬ 
cepto se diferencia del concepto de intervalo utilizado 
anteriormente, que hace referencia a un intervalo de 
tiempo con horas de comienzo y de final específicos 1 . 

23.2.2. Lenguajes para consultas temporales 

Las relaciones de base de datos sin información tem¬ 
poral se denominan a veces relaciones instantáneas, 
ya que reflejan el estado del mundo real en una instan¬ 


tánea. Así, una instantánea de una relación temporal en 
un momento del tiempo t es el conjunto de tupias de la 
relación que son ciertas en el momento t, con los atri¬ 
butos de intervalos de tiempo eliminados. La operación 
instantánea para una relación temporal da la instantá¬ 
nea de la relación en un momento especificado (o en el 
momento actual, si no se especifica el momento). 

Una selección temporal es una selección que impli¬ 
ca a los atributos de tiempo; una proyección tempo¬ 
ral es una proyección en la que las tupias de la pro¬ 
yección heredan los valores de tiempo de las tupias de 
la relación original. Una reunión temporal es una reu¬ 
nión en que los valores temporales de las tupias del 
resultado son la intersección de los valores temporales 
de las tupias de las que proceden. Si los valores tem¬ 
porales no se intersecan, esas tupias se eliminan del 
resultado. 

Los predicados precede , solapa y contiene pueden 
aplicarse a los intervalos; sus significados deben que¬ 
dar claros. La operación intersección puede aplicarse a 
dos intervalos, para dar un único intervalo (posiblemente 
vacío). Sin embargo, la unión de dos intervalos puede 
que no sea un solo intervalo. 

Las dependencias funcionales deben utilizarse con 
cuidado en las relaciones temporales. Aunque puede 
que el número de cuenta determine funcionalmente el 
saldo en cualquier momento, evidentemente el saldo 
puede cambiar con el tiempo. Una dependencia fun¬ 
cional temporal X —> r Y es válida para un esquema de 
relación R si, para todos los casos legales r de R, todas 
las instantáneas de r satisfacen la dependencia funcio¬ 
nal A — y. 

Se han realizado varias propuestas para ampliar SQL 
para mejorar su soporte de los datos temporales. 
SQL: 1999 Parte 7 (SQL/Temporal), que actualmente se 
halla en desarrollo, es el estándar propuesto para las 
extensiones temporales de SQL. 


23.3. DATOS ESPACIALES Y GEOGRÁFICOS 


El soporte de los datos espaciales en las bases de datos 
es importante para el almacenaje, indexado y consulta 
eficientes de los datos basados en las posiciones espa¬ 
ciales. Por ejemplo, supóngase que se desea almacenar 
un conjunto de polígonos en una base de datos y con¬ 
sultar la base de datos para hallar todos los polígonos 
que intersecan un polígono dado. No se pueden utilizar 
las estructuras estándares de índices como los árboles 
B o los índices asociativos para responder de manera 
eficiente esas consultas. El procesamiento eficiente de 


esas consultas necesita estructuras de índices de finali¬ 
dades especiales, como los árboles R (que se estudia¬ 
rán posteriormente). 

Dos tipos de datos espaciales son especialmente 
importantes: 

• Los datos de diseño asistido por computadora 
(Computer-Aided-Design, CAD), que incluyen 
información espacial sobre el modo en que los 
objetos —como los edificios, los coches o los avio- 


' Muchos investigadores de bases de datos temporales consideran 
que este tipo de datos debería haberse denominado span, ya que no 
especifica un momento inicial ni un momento final exactos, sino tan 
sólo el tiempo transcurrido entre los dos. 
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Objeto 

FIGURA 23.2. Representación de estructuras geométricas. 


nes— están construidos. Otros ejemplos impor¬ 
tantes de bases de datos de diseño asistido por com¬ 
putadora son los diseños de circuitos integrados y 
de dispositivos electrónicos. 

• Los datos geográficos como los mapas de carre¬ 
teras, los mapas de uso de la tierra, los mapas topo¬ 
gráficos, los mapas políticos que muestran fronte¬ 
ras, los mapas catastrales, etcétera. 

Los sistemas de información geográfica son bases de 
datos de propósito especial adaptadas para el almace¬ 
namiento de datos geográficos. El soporte para los datos 
geográficos se ha añadido a muchos sistemas de bases 
de datos, como IBM DB2 Spatial Extender, Informix 
Spatial Datablade u Oracle Spatial. 

23.3.1. Representación de la información 
geométrica 

La Figura 23.2 muestra el modo en que se pueden repre¬ 
sentar de manera normalizada en las bases de datos varias 
estructuras geométricas. Hay que destacar aquí que la 


{(x-i.yfi, (x 2 ,y 2 )} 


{(xvyfi, (x 2 ,y 2 ), (x 3 ,y 3 )} 


{(xvyfi, (x 2 ,y 2 ), (x 3 ,y 3 ), (x 4 ,y 4 ), (x 5 ,y 5 )} 


{(xi,y-|), (x 2 ,y 2 ), (x 3 ,y 3 ), IDfi 
{(Xi.yfi, (x 3 ,y 3 ), (x 4 ,y 4 ), ID,} 
{(x v yi), (x 4 ,y 4 ), (x 5 ,y 5 ), ID,} 


Representación 


información geométrica puede representarse de varias 
maneras diferentes, de las que sólo se describen algunas. 

Un segmento rectilíneo puede representarse median¬ 
te las coordinadas de sus extremos. Por ejemplo, en una 
base de datos de mapas, las dos coordenadas de un pun¬ 
to serían su latitud y su longitud. Una línea poligonal 
(también denominada línea quebrada ) consiste en una 
secuencia conectada de segmentos rectilíneos, y pue¬ 
den representarse mediante una lista que contenga las 
coordenadas de los extremos de los segmentos, en 
secuencia. Se puede representar aproximadamente una 
curva arbitraria mediante líneas poligonales, dividien¬ 
do la curva en una serie de segmentos. Esta representa¬ 
ción resulta útil para elementos bidimensionales como 
las carreteras; en este caso, la anchura de la carretera es 
lo bastante pequeña en relación con el tamaño de todo 
el mapa que puede considerarse bidimensional. Algu¬ 
nos sistemas también soportan como primitivas los arcos 
de circunferencia, lo que permite que las curvas se repre¬ 
senten como secuencias de arcos. 

Los polígonos pueden representarse indicando sus 
vértices en orden, como en la Figura 23.2 2 . La lista de 


2 Algunas referencias utilizan el término polígono cerrado para hacer 
referencia a lo que aquí se denominan polígonos y se refieren a las 
líneas poligonales abiertas como polígonos abiertos. 
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los vértices especifica la frontera de cada región poli¬ 
gonal. En una representación alternativa cada polígono 
puede dividirse en un conjunto de triángulos, como se 
muestra en la Figura 23.2. Este proceso se denomina 
triangulación, y se puede triangular cualquier polígo¬ 
no. Se concede un identificador a cada polígono com¬ 
plejo, y cada uno de los triángulos en los que se divide 
lleva el identificador del polígono. Los círculos y las 
elipses pueden representarse por los tipos correspon¬ 
dientes, o aproximarse mediante polígonos. 

Las representaciones de las líneas poligonales o de 
los polígonos basadas en listas suelen resultar conve¬ 
nientes para el procesamiento de consultas. Esas repre¬ 
sentaciones que no están en la primera forma normal se 
utilizan cuando están soportadas por la base de datos 
subyacente. Para que se puedan utilizar tupias de tama¬ 
ño fijo (en la primera forma normal) para la represen¬ 
tación de líneas poligonales se puede dar a la línea poli¬ 
gonal o a la curva un identificador, y se puede representar 
cada segmento como una tupia separada que también 
lleva el identificador de la línea poligonal o de la cur¬ 
va. De manera parecida, la representación triangulada 
de los polígonos permite una representación relacio- 
nal de los polígonos en su primera forma normal. 

La representación de los puntos y de los segmentos 
rectilíneos en el espacio tridimensional es parecida a 
su representación en el espacio bidimensional, siendo 
la única diferencia que los puntos tienen un compo¬ 
nente 2 adicional. De manera parecida, la representa¬ 
ción de las figuras planas —como los triángulos, los 
rectángulos y otros polígonos— no cambia mucho 
cuando se pasa a tres dimensiones. Los tetraedros y los 
paralelepípedos pueden representarse de la misma 
manera que los triángulos y los rectángulos. Se pueden 
representar poliedros arbitrarios dividiéndolos en tetra¬ 
edros, igual que se triangulan los polígonos. También 
se pueden representar indicando las caras, cada una de 
las cuales es, en sí misma, un polígono, junto con una 
indicación del lado de la cara que está por dentro del 
poliedro. 


23.3.2. Bases de datos de diseño 

Los sistemas de diseño asistido por computadora 
(Computer-Aided-Design, CAD) tradicionalmente 
almacenaban los datos en la memoria durante su edi¬ 
ción u otro tipo de procesamiento y los volvían a escri¬ 
bir en archivos al final de la sesión de edición. Entre los 
inconvenientes de este esquema están el coste (la com¬ 
plejidad de programación y el coste temporal) de trans¬ 
formar los datos de una forma a otra, y la necesidad de 
leer todo un archivo aunque sólo sea necesaria una par¬ 
te. Para los diseños de gran tamaño, como el diseño de 
circuitos integrados a gran escala o el diseño de todo un 
avión, puede que resulte imposible guardar en la memo¬ 
ria el diseño completo. Los diseñadores de bases de 
datos orientadas a objetos estaban motivados en gran 
parte por las necesidades de los sistemas de CAD. Las 
bases de datos orientadas a objetos representan los com¬ 
ponentes del diseño como objetos y las conexiones entre 
los objetos indican el modo en que está estructurado el 
diseño. 

Los objetos almacenados en las bases de datos de 
diseño suelen ser objetos geométricos. Entre los obje¬ 
tos geométricos bidimensionales sencillos están los pun¬ 
tos, las líneas, los triángulos, los rectángulos y los polí¬ 
gonos en general. Los objetos bidimensionales complejos 
pueden formarse a partir de objetos sencillos mediante 
las operaciones de unión, intersección y diferencia. De 
manera parecida, los objetos tridimensionales comple¬ 
jos pueden formarse a partir de objetos más sencillos 
como las esferas, los cilindros y los paralelepípedos 
mediante las operaciones unión, intersección y dife¬ 
rencia, como en la Figura 23.3. Las superficies tridi¬ 
mensionales también pueden representarse mediante 
modelos de alambres, que esencialmente modelan las 
superficies como conjuntos de objetos más sencillos, 
como segmentos rectilíneos, triángulos y rectángulos. 

Las bases de datos de diseño también almacenan 
información no espacial sobre los objetos, como el mate¬ 
rial del que están construidos. Se suele poder modelar 



(a) Diferencia de cilindros 



FIGURA 23.3. Objetos tridimensionales complejos. 
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esa información mediante técnicas estándar de mode¬ 
lado de datos. Aquí se centrará la atención únicamente 
en los aspectos espaciales. 

Al diseñar hay que realizar varias operaciones espa¬ 
ciales. Por ejemplo, puede que el diseñador desee recu¬ 
perar la parte del diseño que corresponde a una región 
de interés determinada. Las estructuras espaciales de 
índices, estudiadas en el Apartado 23.3.5, resultan úti¬ 
les para estas tareas. Las estructuras espaciales de índi¬ 
ces son multidimensionales, trabajan con datos de dos 
y de tres dimensiones, en vez de trabajar solamente con 
la sencilla ordenación unidimensional que proporcio¬ 
nan los árboles B + . 

Las restricciones de integridad espacial, como «dos 
tuberías no deben estar en la misma ubicación», son 
importantes en las bases de datos de diseño para evitar 
errores por interferencias. Estos errores suelen produ¬ 
cirse si el diseño se realiza a mano y sólo se detectan al 
construir un prototipo. En consecuencia, estos errores 
pueden resultar costosos de reparar. El soporte de las 
bases de datos para las restricciones de integridad espa¬ 
cial ayuda a los usuarios a evitar los errores de diseño, 
con lo que hacen que el diseño sea consistente. La imple- 
mentación de esas verificaciones de integridad depen¬ 
de una vez más de la disponibilidad de estructuras mul¬ 
tidimensionales de índices eficientes. 

23.3.3. Datos geográficos 

Los datos geográficos son de naturaleza espacial, pero 
se diferencian de los datos de diseño en ciertos aspec¬ 
tos. Los mapas y las imágenes de satélite son ejemplos 
típicos de datos geográficos. Los mapas pueden pro¬ 
porcionar no sólo información sobre la ubicación —so¬ 
bre fronteras, ríos y carreteras, por ejemplo— sino tam¬ 
bién información mucho más detallada asociada con la 
ubicación, como la elevación, el tipo de suelo, el uso de 
la tierra y la cantidad anual de lluvia. 

Los datos geográficos pueden clasificarse en dos 
tipos: 

• Los datos por líneas. Estos datos consisten en mapas 
de bits o en mapas de píxeles en dos o más dimen¬ 
siones. Un ejemplo típico de imagen de líneas bidi- 
mensional son las imágenes de satélite de cobertura 
nubosa, en las que cada píxel almacena la visibili¬ 
dad de nubes en un área concreta. Estos datos pue¬ 
den ser tridimensionales, por ejemplo, la tempera¬ 
tura a diferentes altitudes en distintas regiones, 
también medidas con la ayuda de un satélite. El tiem¬ 
po puede formar otra dimensión, por ejemplo, las 
medidas de la temperatura superficial en diferentes 
momentos. Las bases de datos de diseño no suelen 
almacenar datos por líneas. 

• Los datos vectoriales. Los datos vectoriales están 
formados a partir de objetos geométricos básicos 
como los puntos, los segmentos rectilíneos, los 
triángulos y otros polígonos en dos dimensiones y 


los cilindros, las esferas, los paralelepípedos y otros 
poliedros en tres dimensiones. 

Los datos de los mapas suelen representarse en 
formato vectorial. Los ríos y las carreteras pueden 
representarse como uniones de varios segmentos 
rectilíneos. Los estados y los países pueden repre¬ 
sentarse como polígonos. La información topoló- 
gica como la altura puede representarse mediante 
una superficie dividida en polígonos que cubren 
las regiones de igual altura, con un valor de altu¬ 
ra asociado a cada polígono. 

23.3.3.1. Representación de los datos 
geográficos 

Los accidentes geográficos, como los estados y los gran¬ 
des lagos, se representan como polígonos complejos. 
Algunos accidentes, como los ríos, pueden represen¬ 
tarse como curvas complejas o como polígonos com¬ 
plejos, en función de si su anchura es importante o no. 

La información geográfica relativa a las regiones, 
como la cantidad anual de lluvia, puede representarse 
como un array, es decir, en forma de líneas. En aras de 
la eficiencia del espacio, el array puede almacenarse de 
manera comprimida. En el Apartado 23.3.5 se estudia 
una representación alternativa de estas arrays mediante 
una estmctura de datos denominada árbol cuadrático. 

Como se indicó en el Apartado 23.3.3, se puede 
representar la información regional en forma vectorial 
empleando polígonos, cada uno de los cuales es una 
región en la que el valor del array es el mismo. La repre¬ 
sentación vectorial es más compacta que la de líneas en 
algunas aplicaciones. También es más precisa para algu¬ 
nas tareas, como el dibujo de carreteras, en que la divi¬ 
sión de la región en píxeles (que pueden ser bastante 
grandes) lleva a una pérdida de precisión en la infor¬ 
mación de ubicación. No obstante, la representación 
vectorial resulta inadecuada para las aplicaciones en que 
los datos se basan en líneas de manera intrínseca, como 
las imágenes de satélite. 

23.3.3.2. Aplicaciones de los datos geográficos 

Las bases de datos geográficas tienen gran variedad de 
usos, incluidos los servicios de mapas en línea, los sis¬ 
temas de navegación para vehículos, la información de 
redes de distribución para las empresas de servicios 
públicos como son los sistemas de telefonía, electrici¬ 
dad y suministro de agua y la información de uso de la 
tierra para ecologistas y planificadores. 

Los servicios de mapas de carreteras basados en la 
web constituyen una aplicación muy utilizada de datos 
de mapas. En su nivel más sencillo estos sistemas pue¬ 
den utilizarse para generar mapas de carreteras en línea 
de la región deseada. Una ventaja importante de los 
mapas interactivos es que resulta sencillo dimensionar 
los mapas al tamaño deseado, es decir, acercarse y ale¬ 
jarse para ubicar los accidentes importantes. Los servi¬ 
cios de mapas de carretera también almacenan infor- 
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mación sobre carreteras y servicios, como el trazado de 
las carreteras, los límites de velocidad, las condiciones 
de las vías, las conexiones entre carreteras y los tramos 
de sentido único. Con esta información adicional sobre 
las carreteras se pueden utilizar los mapas para obtener 
indicaciones para desplazarse de un sitio a otro y para 
localizar, por ejemplo, hoteles, gasolineras o restauran¬ 
tes con las ofertas y gamas de precios deseadas. 

Los sistemas de navegación para los vehículos son 
sistemas montados en automóviles que proporcionan 
mapas de carreteras y servicios para la planificación de 
los viajes. Un añadido útil a los sistemas de informa¬ 
ción geográfica móviles como los sistemas de navega¬ 
ción de los vehículos es una unidad del sistema de posi- 
cionamiento global (Global Positioning System, 
GPS), que utiliza la información emitida por los saté¬ 
lites GPS para hallar la ubicación actual con una preci¬ 
sión de decenas de metros. Con estos sistemas el con¬ 
ductor no puede perderse nunca 3 : la unidad GPS halla 
la ubicación en términos de latitud, longitud y eleva¬ 
ción y el sistema de navegación puede consultar la base 
de datos geográfica para hallar el lugar en que se encuen¬ 
tra y la carretera en que se halla el vehículo. 

Las bases de datos geográficas para información de 
utilidad pública se están volviendo cada vez más impor¬ 
tantes a medida que crece la red de cables y tuberías 
enterrados. Sin mapas detallados las obras realizadas 
por una empresa de servicio público pueden dañar los 
cables de otra, lo que daría lugar a una interrupción del 
servicio a gran escala. Las bases de datos geográficas, 
junto con los sistemas precisos de determinación de la 
posición, pueden ayudar a evitar estos problemas. 

Hasta ahora se ha explicado el motivo de que las 
bases de datos espaciales resulten útiles. En el resto del 
apartado se estudiarán los detalles técnicos, como la 
representación y el indexado de la información espa¬ 
cial. 

23.3.4. Consultas espaciales 

Hay varios tipos de consultas que implican a las ubica¬ 
ciones espaciales. 

• Las consultas de proximidad solicitan objetos 
que se hallen cerca de una ubicación especificada. 
La consulta para hallar todos los restaurantes que 
se hallan a menos de una distancia dada de un 
determinado punto es un ejemplo de consulta de 
proximidad. La consulta de vecino más próximo 
solicita el objeto que se halla más próximo al pun¬ 
to especificado. Por ejemplo, puede que se desee 
hallar la gasolinera más cercana. Obsérvese que 
esta consulta no tiene que especificar un límite para 
la distancia y, por tanto, se puede formular aunque 
no se tenga idea de la distancia a la que se halla la 
gasolinera más próxima. 


3 Bueno, ¡casi nunca! 


• Las consultas regionales tratan de regiones espa¬ 
ciales. Estas consultas pueden preguntar por obje¬ 
tos que se hallen parcial o totalmente en el interior 
de la región especificada. Un ejemplo es la con¬ 
sulta para hallar todas las tiendas minoristas den¬ 
tro de los límites geográficos de una ciudad dada. 

• Puede que las consultas también soliciten inter¬ 
secciones y uniones de regiones. Por ejemplo, dada 
la información regional, como pueden ser la llu¬ 
via anual y la densidad de población, una consul¬ 
ta puede solicitar todas las regiones con una baja 
cantidad de lluvia anual y una elevada densidad de 
población. 

Las consultas que calculan las intersecciones de 
regiones pueden considerarse como si calcularan la reu¬ 
nión espacial de dos relaciones espaciales —por ejem¬ 
plo, una que represente la cantidad de lluvia y otra que 
represente la densidad de población— con la ubicación 
en el papel de atributo de reunión. En general, dadas 
dos relaciones, cada una de las cuales contiene objetos 
espaciales, la reunión espacial de las dos relaciones 
genera pares de objetos que se intersectan o las regio¬ 
nes de intersección de esos pares. 

Varios algoritmos de reunión calculan de manera efi¬ 
ciente las reuniones espaciales de datos vectoriales. Aun¬ 
que se pueden utilizar las reuniones de bucles anidados 
o de bucles anidados indexados (con índices espacia¬ 
les), las reuniones de asociación y las reuniones por 
mezcla-ordenación no pueden utilizarse con datos espa¬ 
ciales. Los investigadores han propuesto técnicas de 
reunión basadas en el recorrido coordinado de las estruc¬ 
turas espaciales de los índices de las dos relaciones. 
Véanse las notas bibliográficas para obtener más infor¬ 
mación. 

En general, las consultas de datos espaciales pueden 
tener una combinación de requisitos espaciales y no 
espaciales. Por ejemplo, puede que se desee averiguar 
el restaurante más cercano que tenga menú vegetaria¬ 
no y que cueste menos de diez euros por comida. 

Dado que los datos espaciales son inherentemente 
gráficos, se suelen consultar mediante un lenguaje grá¬ 
fico de consulta. El resultado de esas consultas también 
se muestra gráficamente, en vez de mostrarse en tablas. 
El usuario puede realizar varias operaciones con la inter¬ 
faz, como escoger el área que desea ver (por ejemplo, 
apuntando y pulsando en los barrios del oeste de Argan- 
zuela), acercarse y alejarse, escoger lo que desea mos¬ 
trar de acuerdo con las condiciones de selección (por 
ejemplo, casas con más de tres habitaciones), superpo¬ 
ner varios mapas (por ejemplo, las casas con más de tres 
habitaciones superpuestas sobre un mapa que muestre 
las zonas con bajas tasas de delincuencia), etcétera. La 
interfaz gráfica constituye la parte visible para el usua¬ 
rio. Se han propuesto extensiones de SQL para permi¬ 
tir que las bases de datos relaciónales almacenen y recu- 
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peren información espacial de manera eficiente y tam¬ 
bién permitir que las consultas mezclen las condiciones 
espaciales con las no espaciales. Las extensiones inclu¬ 
yen la autorización de tipos de datos abstractos como 
las líneas, los polígonos y los mapas de bits y la auto¬ 
rización de condiciones espaciales como contiene o sola¬ 
pa. 

23.3.5. Indexado de los datos espaciales 

Los índices son necesarios para el acceso eficiente a los 
datos espaciales. Las estructuras de índices tradiciona¬ 
les, como los índices de asociación y los árboles B, no 
resultan adecuadas, ya que sólo trabajan con datos uni¬ 
dimensionales, mientras que los datos espaciales sue¬ 
len ser de dos o más dimensiones. 

23.3.5.1. Los árboles k-d 

Para comprender el modo de indexar los datos espacia¬ 
les que constan de dos o más dimensiones se conside¬ 
ra en primer lugar el indexado de los puntos de los datos 
unidimensionales. Las estructuras arbóreas, como los 
árboles binarios y los árboles B, operan dividiendo el 
espacio en partes más pequeñas de manera sucesiva. 
Por ejemplo, cada nodo interno de un árbol binario divi¬ 
de un intervalo unidimensional en dos. Los puntos que 
quedan en la partición izquierda van al subárbol izquier¬ 
do; los puntos que quedan en la partición de la derecha 
van al subárbol derecho. En los árboles binarios equi¬ 
librados la partición se escoge de modo que, aproxi¬ 
madamente, la mitad de los puntos almacenados en el 
subárbol caigan en cada partición. De manera parecida, 
cada nivel de un árbol B divide un intervalo unidimen¬ 
sional en varias partes. 

Se puede utilizar esa intuición para crear estmcturas 
arbóreas para el espacio bidimensional, así como para 
espacios de más dimensiones. Una estructura arbórea 
denominada árbol k-d fue una de las primeras estmc¬ 
turas utilizadas para la indexación en varias dimensio¬ 
nes. Cada nivel de un árbol k-d divide el espacio en dos. 
La división se realiza según una dimensión en el nodo 
del nivel superior del árbol, según otra dimensión en los 
nodos del nivel siguiente, etcétera, alternando cíclica¬ 
mente las dimensiones. La división se realiza de tal modo 
que, en cada nodo, aproximadamente la mitad de los 
puntos almacenados en el subárbol cae a un lado y la 
otra mitad al otro. La división se detiene cuando un nodo 
tiene menos puntos que un valor máximo dado. La Figu¬ 
ra 23.4 muestra un conjunto de puntos en el espacio bidi¬ 
mensional y una representación en árbol k-d de ese con¬ 
junto de puntos. Cada línea corresponde a un nodo del 
árbol, y el número máximo de puntos en cada nodo hoja 
se ha definido como uno. Cada línea de la figura (apar¬ 
te del marco exterior) corresponde a un nodo del árbol 
k-d. La numeración de las líneas en la figura indica el 
nivel del árbol en el que aparece el nodo correspondiente. 

El árbol k-d-B extiende el árbol k-d para permitir 
varios nodos hijo por cada nodo interno, igual que los 
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FIGURA 23.4. División del espacio por un árbol k-d. 


árboles B extienden los árboles binarios, para reducir la 
altura del árbol, los árboles k-d-B están mejor adapta¬ 
dos al almacenamiento secundario que los árboles k-d. 

23.3.5.2. Árboles cuadráticos 

Una representación alternativa de los datos bidimen- 
sionales son los árboles cuadráticos. En la Figura 23.5 
aparece un ejemplo de la división del espacio median¬ 
te un árbol cuadrático. El conjunto de puntos es el mis¬ 
mo que en la Figura 23.4. Cada nodo de un árbol cua- 



FIGURA 23.5. División del espacio por un árbol cuadrático. 
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drático está asociado con una región rectangular del 
espacio. El nodo superior está asociado con todo el 
espacio objetivo. Cada nodo que no sea un nodo hoja 
del árbol cuadrático divide su región en cuatro cua¬ 
drantes del mismo tamaño y, a su vez, cada uno de esos 
nodos tiene cuatro nodos hijo correspondientes a los 
cuatro cuadrantes. Los nodos hoja tienen un número de 
puntos que varía entre cero y un número máximo fija¬ 
do. A su vez, si la región correspondiente a un nodo tie¬ 
ne más puntos que el máximo fijado, se crean nodos 
hijo para ese nodo. En el ejemplo de la Figura 23.5, el 
número máximo de puntos de cada nodo hoja está fija¬ 
do en uno. 

Este tipo de árbol cuadrático se denomina árbol 
cuadrático PR, para indicar que almacena los puntos 
y que la división del espacio se basa en regiones, en 
vez de en el conjunto real de puntos almacenados. Se 
pueden utilizar árboles cuadráticos regionales para 
almacenar información de arrays (de líneas). Cada nodo 
de los árboles cuadráticos regionales es un nodo hoja 
si todos los valores del array de la región que abarca 
son iguales. En caso contrario, se vuelve a subdividir 
en cuatro nodos hijo con la misma área y es, por tan¬ 
to, un nodo interno. Cada nodo del árbol cuadrático 
regional corresponde a un subarray de valores. Los 
subarrays correspondientes a las hojas contienen un 
solo elemento del array o varios, todos ellos con el mis¬ 
mo valor. 

El indexado de los segmentos rectilíneos y de los 
polígonos presenta problemas nuevos. Hay extensiones 
de los árboles k-d y de los árboles cuadráticos para esta 
labor. No obstante, un segmento rectilíneo o un polí¬ 
gono puede cruzar una línea divisoria. Si lo hace, hay 
que dividirlo y representarlo en cada uno de los subár¬ 
boles en que aparezcan sus fragmentos. La aparición 
múltiple de un segmento lineal o de un polígono puede 
dar lugar a ineficiencias en el almacenamiento, así como 
a ineficiencias en las consultas. 


23.3.5.3. Árboles R 

Una estructura de almacenamiento denominada árbol 
R resulta útil para el indexado de los rectángulos y de 
otros polígonos. Un árbol R es una estructura arbórea 
equilibrada con los polígonos indexados almacenados 
en los nodos hoja, de manera parecida a los árboles B + . 
No obstante, en lugar de un rango de valores, se asocia 
una caja límite con cada nodo del árbol. La caja lími¬ 
te de un nodo hoja es el rectángulo mínimo paralelo a 
los ejes que contiene todos los objetos almacenados en 
el nodo hoja. La caja límite de los nodos internos, de 
manera parecida, es el rectángulo mínimo paralelo a los 
ejes que contiene las cajas límite de sus nodos hijo. La 
caja límite de un polígono viene definida, de manera 
parecida, como el rectángulo mínimo paralelo a los ejes 
que contiene al polígono. 

Cada nodo interno almacena las cajas límite de los 
nodos hijo junto con los punteros para los nodos hijo. Cada 
nodo hijo almacena los polígonos indexados y puede que, 
opcionalmente, almacene las cajas límite de esos polígo¬ 
nos; las cajas límite ayudan a acelerar las comprobacio¬ 
nes de solapamientos de los rectángulos con los polígo¬ 
nos indexados —si el rectángulo de una consulta no se 
solapa con la caja límite de un polígono, o no se puede 
solapar tampoco el polígono. (Si los polígonos indexados 
son rectángulos, por supuesto no hace falta almacenar las 
cajas límite, ya que son idénticas a los rectángulos.) 

La Figura 23.6 muestra el ejemplo de un conjunto de 
rectángulos (dibujados con línea continua) y de sus cajas 
límite (dibujadas con línea discontinua) de los nodos de 
un árbol R para el conjunto de rectángulos. Hay que tener 
en cuenta que las cajas límite se muestran con espacio 
adicional en su interior, para hacerlas visibles en el dibu¬ 
jo. En realidad, las cajas son menores y se ajustan fiel¬ 
mente a los objetos que contienen; es decir, cada cara de 
una caja límite C toca como mínimo uno de los objetos 
o de las cajas límite que se contienen en C. 


o 




FIGURA 23.6. Árbol R. 
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El árbol R en sí se halla a la derecha de la Figura 
23.6. La figura hace referencia a las coordenadas de la 
caja límite i como CL r 

Ahora se verá el modo de implementar las opera¬ 
ciones de búsqueda, inserción y eliminación en los árbo¬ 
les R. 

• Búsqueda: Como muestra la figura, las cajas lími¬ 
te con nodos hermanos pueden solaparse; en los 
árboles B + , los árboles k-d y los árboles cuadráti- 
cos, sin embargo, los rangos no se solapan. La bús¬ 
queda de polígonos que contengan un punto, por 
tanto, tiene que seguir todos los nodos hijo cuyas 
cajas limites asociadas contengan el punto; en con¬ 
secuencia, puede que haya que buscar por varios 
caminos. De manera parecida, una consulta para 
buscar todos los polígonos que intersecten con uno 
dado tiene que bajar por todos los nodos en que el 
rectángulo asociado intersecte al polígono. 

• Inserción: Cuando se inserta un polígono en un 
árbol R se selecciona un nodo hoja para que lo 
guarde. Lo ideal sería seleccionar un nodo hoja 
que tuviera espacio para guardar una nueva entra¬ 
da, y cuya caja límite contuviera a la caja límite 
del polígono. Sin embargo, puede que ese nodo no 
exista; aunque exista, hallarlo puede resultar muy 
costoso, ya que no es posible hallarlo mediante un 
solo recorrido desde la raíz. En cada nodo interno 
se pueden encontrar varios nodos hijo cuyas cajas 
límite contengan la caja límite del polígono, y hay 
que explorar cada uno de esos nodos hijo. Por tan¬ 
to, como norma heurística, en un recorrido desde 
la raíz, si alguno de los nodos hijo tiene una caja 
límite que contenga a la caja límite del polígono, 
el algoritmo del árbol R escoge una de ellas de 
manera arbitraria. Si ninguno de los nodos hijo 
satisface esta condición, el algoritmo escoge un 
nodo hijo cuya caja límite tenga el solapamiento 
máximo con la caja límite del polígono para con¬ 
tinuar el recorrido. 

Una vez que se ha llegado al nodo hoja, si el 
nodo ya está lleno, el algoritmo lleva a cabo una 
división del nodo (y propaga hacia arriba la divi¬ 
sión si es necesario) de manera muy parecida a la 
inserción de los árboles B + . Igual que con la inser¬ 
ción en los árboles B + , el algoritmo de inserción 
de los árboles R asegura que el árbol siga equili¬ 
brado. Además, asegura que las cajas límite de los 
nodos hoja, así como los nodos intemos, sigan sien¬ 
do consistentes; es decir, las cajas límite de los 
nodos hoja contienen todas las cajas límites de los 
polígonos almacenados en el nodo hoja, mientras 
que las cajas límite de los nodos intemos contie¬ 
nen todas las cajas límite de los nodos hijo. 

La principal diferencia del procedimiento de 
inserción con la inserción en los árboles B + radica 
en el modo en que se dividen los nodos. En los 
árboles B + es posible hallar un valor tal que la mitad 


de los de las entradas sea menor que el punto medio 
y la mitad sea mayor que el valor. Esta propiedad 
no se generaliza más allá de una dimensión; es 
decir, para más de una dimensión, no siempre es 
posible dividir las entradas en dos conjuntos tales 
que sus cajas límite no se solapen. En lugar de eso, 
como norma heurística, el conjunto de entradas S 
puede dividirse en dos conjuntos disjuntos Sj y S 2 
tales que las cajas límite de Sj y S 2 tengan un área 
total mínima; otra norma heurística sería dividir 
las entradas en dos conjuntos S, y S 2 de modo que 
S j y Si, tengan un solapamiento mínimo. Los dos 
nodos resultantes de la división contendrían las 
entradas de Sj y S 2 , respectivamente. El coste de 
hallar las divisiones con área total o solapamien¬ 
to mínimos puede ser elevado, por lo que se utili¬ 
zan normas heurísticas más económicas, como la 
heurística de la división cuadrática. (La heurísti¬ 
ca recibe el nombre del hecho de que toma el cua¬ 
drado del tiempo en el número de entradas.) 

La heurística de la división cuadrática funcio¬ 
na de esta manera: En primer lugar, selecciona un 
par de entradas ay b de S tales que al ponerlas en 
el mismo nodo den lugar a una caja límite con el 
máximo de espacio desaprovechado; es decir, el 
área de la caja límite mínima de a y b menos la 
suma de las áreas de a y b es máxima. La heurísti¬ 
ca sitúa las entradas ay b en los conjuntos 5) y S 2 , 
re specti v amente. 

Luego añade de manera iterativamente las entra¬ 
das restantes, una por cada iteración, a uno de los 
dos conjuntos S¡ o S 2 . En cada iteración, para cada 
entrada restante e, i e l denota el incremento en el 
tamaño de la caja límite de S, si e se añade a 6', e 
i e 2 denota el incremento correspondiente de S 2 . En 
cada iteración la heurística escoge una de las entra¬ 
das con la máxima diferencia entre i e , e i e2 y la aña¬ 
de a Sj si i el es menor que i e2 , ya S 2 en caso con¬ 
trario. Es decir, se escoge en cada iteración una 
entrada con «preferencia máxima» por S¡ o S 2 . Las 
iteraciones se detienen cuando se han asignado 
todas las entradas o cuando uno de los conjuntos 
Sj o S 2 tiene entradas suficientes como para que 
todas las demás entradas haya que añadirlas al otro 
conjunto de modo que los nodos creados a partir 
de S t y S 2 tengan la ocupación mínima exigida. La 
heurística añade luego todas las entradas no asig¬ 
nadas al conjunto con menos entradas. 

• Eliminación: La eliminación puede llevarse a cabo 
como si fuera una eliminación de árbol B + , toman¬ 
do prestadas las entradas de los nodos hermanos, 
o mezclando nodos hermanos si un nodo se que¬ 
da menos lleno de lo exigido. Un enfoque alter¬ 
nativo redistribuye todas las entradas de los nodos 
menos llenos de lo necesario a los nodos herma¬ 
nos, con el objetivo de mejorar el agrupamiento de 
las entradas en el árbol R. 
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Véanse las referencias bibliográficas para obtener 
más detalles de las operaciones de inserción y de eli¬ 
minación en los árboles R, así como de las variantes de 
los árboles R, denominados árboles R* o árboles R + . 

La eficiencia del almacenamiento de los árboles R 
es mayor que la de los árboles k-d y que la de los árbo¬ 
les cuadráticos, ya que cada polígono sólo se almacena 
una vez, y se puede asegurar que cada nodo está, como 
mínimo, medio lleno. No obstante, las consultas pue¬ 


den resultar más lentas, ya que hay que buscar por varios 
caminos. Las reuniones espaciales son más sencillas 
con los árboles cuadráticos que con los árboles R, ya 
que todos los árboles cuadráticos de cada región están 
divididos de la misma manera. Sin embargo, debido a 
su mayor eficiencia de almacenamiento, y a su pareci¬ 
do con los árboles B, los árboles R y sus variantes se 
han hecho populares en los sistemas de bases de datos 
que soportan datos espaciales. 


23.4. BASES DE DATOS MULTIMEDIA 


Los datos multimedia, como las imágenes, el sonido y 
el vídeo —una modalidad de datos cada vez más popu¬ 
lar— se almacenan hoy en día casi siempre fuera de las 
bases de datos, en sistemas de archivos. Este tipo de 
almacenamiento no supone ningún problema cuando el 
número de objetos multimedia es relativamente peque¬ 
ño, ya que las características proporcionadas por las 
bases de datos no suelen ser importantes. 

Sin embargo, las características de las bases de datos 
se vuelven importantes cuando el número de objetos 
multimedia almacenados es grande. Aspectos como las 
actualizaciones transaccionales, las facilidades de con¬ 
sulta y el indexado se vuelven importantes. Los objetos 
multimedia suelen tener atributos descriptivos, como 
los que indican su fecha de creación, su creador y la 
categoría a la que pertenecen. Un enfoque de la crea¬ 
ción de una base de datos para esos objetos multimedia 
es utilizar las bases de datos para almacenar los atribu¬ 
tos descriptivos y realizar un seguimiento de los archi¬ 
vos en los que se almacenan los objetos multimedia. 

Sin embargo, el almacenamiento de los objetos mul¬ 
timedia fuera de la base de datos hace más difícil pro¬ 
porcionar la funcionalidad de la base de datos, como el 
indexado con base en el contenido real de datos multi¬ 
media. También puede llevar a inconsistencias, como que 
un archivo esté registrado en la base de datos pero que 
sus contenidos falten, o viceversa. Por tanto, resulta dese¬ 
able almacenar los propios datos en la base de datos. 

Hay que abordar varios aspectos si se pretende alma¬ 
cenar los datos multimedia en una base de datos. 

• La base de datos debe soportar objetos de gran 
tamaño, ya que los datos multimedia como los 
vídeos pueden ocupar varios gigabytes de espacio 
de almacenamiento. Los objetos de mayor tama¬ 
ño pueden dividirse en fragmentos menores y alma¬ 
cenarse en la base de datos. De manera alternati¬ 
va, los objetos multimedia pueden almacenarse en 
un sistema de archivos, pero la base de datos pue¬ 
de contener un puntero hacia el objeto; el puntero 
suele ser un nombre de archivo. El estándar 
SQL/MED (MED significa Management of Exter- 
nal Data, gestión de datos externos), que está en 
desarrollo, permite que los datos externos, como 


los archivos, se traten como si formaran parte de 
la base de datos. Con SQL/MED parece que los 
objetos son parte de la base de datos, pero pueden 
almacenarse externamente. 

Los formatos de los datos multimedia se estu¬ 
dian en el Apartado 23.4.1. 

• La recuperación de algunos tipos de datos, como 
los de sonido y los de vídeo, tiene la exigencia de 
que la entrega de los datos debe realizarse a una 
velocidad constante garantizada. Estos datos se 
denominan a veces datos isócronos o datos de 
medios continuos. Por ejemplo, si los datos de 
sonido no se proporcionan a tiempo, habrá saltos 
en el sonido. Si los datos se proporcionan dema¬ 
siado deprisa, se pueden desbordar los búferes, lo 
que dará lugar a la pérdida de datos. Los datos de 
medios continuos se estudian en el Apartado 23.4.2. 

• La recuperación basada en la semejanza es nece¬ 
saria en muchas aplicaciones de bases de datos 
multimedia. Por ejemplo, en una base de datos que 
almacene imágenes de huellas digitales, se pro¬ 
porciona una consulta de la imagen de una huella 
dactilar y hay que recuperar las huellas dactilares 
de la base de datos que sean parecidas a la huella 
dactilar de la consulta. Las estructuras de índices 
como los árboles B + y los árboles R no se pueden 
utilizar para esta finalidad; hay que crear estruc¬ 
turas especiales de índices. La recuperación basa¬ 
da en el parecido se estudia en el Apartado 23.4.3 

23.4.1. Formatos de datos multimedia 

Debido al gran número de bytes necesarios para repre¬ 
sentar los datos multimedia es fundamental que se alma¬ 
cenen y transmitan de manera comprimida. Para los 
datos de imágenes el formato más utilizado es JPEG , 
que recibe su nombre del organismo de normalización 
que lo creó, el Joint Picture Experts Group, el grupo 
conjunto de expertos en imágenes. Se pueden almace¬ 
nar los datos de vídeo codificando cada fotograma de 
vídeo en formato JPEG, pero esa codificación supone 
un desperdicio, ya que los fotogramas de vídeo sucesi¬ 
vos suelen ser casi iguales. El Moving Picture Experts 
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Group, grupo de expertos en películas, desarrolló la serie 
de estándares MPEG para codificar los datos de vídeo 
y de sonido; estas codificaciones aprovechan las simi¬ 
litudes de las secuencias de fotogramas para conseguir 
un grado de compresión mayor. El estándar MPEG-1 
almacena un minuto de vídeo y sonido a treinta foto¬ 
gramas por segundo en unos 12.5 megabytes (en com¬ 
paración con los aproximadamente 75 megabytes sólo 
para vídeo en JPEG). No obstante, la codificación 
MPEG-1 introduce alguna pérdida de calidad del vídeo, 
a un nivel aproximadamente equivalente al de las cin¬ 
tas de vídeo VHS. 

El estándar MPEG-2 se diseñó para los sistemas de 
radiodifusión digitales y para los discos de vídeo digi¬ 
tales (DVD); sólo introduce una pérdida de calidad de 
vídeo despreciable. MPEG-2 comprime un minuto de 
vídeo y de sonido en aproximadamente 17 megabytes. 
Se utilizan varios estándares competidores para la codi¬ 
ficación de sonido, entre ellos MP3, que significa 
MPEG-1 Capa 3, RealAudio y otros formatos. 

23.4.2. Datos de medios continuos 

Los tipos más importantes de datos de medios conti¬ 
nuos son los datos de vídeo y los de sonido (por ejem¬ 
plo, una base de datos de películas). Los sistemas de 
medios continuos se caracterizan por sus requisitos de 
entrega de información en tiempo real: 

• Los datos deben entregarse lo bastante rápido como 
para que no haya saltos en el resultado de sonido 
o de vídeo. 

• Los datos deben entregarse a una velocidad que no 
cause un desbordamiento de los búferes del sistema. 

• La sincronización entre los distintos flujos de datos 
debe conservarse. Esta necesidad surge, por ejem¬ 
plo, cuando el vídeo de una persona que habla 
muestra sus labios moviéndose de manera sincro¬ 
nizada con el sonido de su voz. 

Para proporcionar los datos de manera predecible en 
el momento correcto a un gran número de consumido¬ 
res de los datos la captura de los datos desde el disco 
debe coordinarse cuidadosamente. Generalmente los 
datos se capturan en ciclos periódicos. En cada ciclo, 
digamos de n segundos, se capturan n segundos de datos 
para cada consumidor y se almacenan en los búferes de 
memoria, mientras los datos capturados en el ciclo ante¬ 
rior se envían a los consumidores desde los búferes de 
memoria. El periodo de los ciclos es un compromiso: 
un periodo corto utiliza menos memoria pero necesita 
más movimientos del brazo del disco, lo que supone un 
desperdicio de recursos, mientras que un periodo largo 
reduce el movimiento del brazo del disco pero aumen¬ 
ta las necesidades de memoria y puede retrasar la entre¬ 
ga inicial de datos. Cuando llega una nueva solicitud 
entra en acción el control de admisión: es decir, el sis¬ 
tema comprueba si se puede satisfacer la solicitud con 


los recursos disponibles (en cada periodo); si es así, se 
admite; en caso contrario, se rechaza. 

La extensa investigación realizada sobre la entrega 
de datos de medios continuos ha tratado aspectos como 
el manejo de arrays de discos y el tratamiento de los 
fallos de los discos. Véanse las referencias bibliográfi¬ 
cas para obtener más detalles. 

Varios fabricantes ofrecen servidores de vídeo bajo 
demanda. Los sistemas actuales están basados en los sis¬ 
temas de archivos, ya que los sistemas de bases de datos 
existentes no proporcionan la respuesta en tiempo real 
que necesitan estas aplicaciones. La arquitectura básica 
de un sistema de vídeo bajo demanda comprende: 

• Servidor de vídeo. Los datos multimedia se alma¬ 
cenan en varios discos (generalmente en una con¬ 
figuración RAID). Puede que los sistemas que con¬ 
tienen un gran volumen de datos utilicen medios 
de almacenamiento terciario para los datos a los 
que se tiene acceso con menor frecuencia. 

• Terminales. La gente ve los datos multimedia 
mediante varios dispositivos, colectivamente deno¬ 
minados terminales. Ejemplos son las computa¬ 
doras personales y los televisores conectados a una 
computadora pequeña y de coste reducido deno¬ 
minada microcomputadora. 

• Red. La transmisión de los datos multimedia des¬ 
de el servidor hasta los terminales necesita una red 
de gran capacidad. 

El servicio de vídeo bajo demanda acabará siendo 
ubicuo, igual que lo son ahora la televisión por ondas 
hercianas y la televisión por cable. En el momento actual 
las aplicaciones principales de la tecnología de los video¬ 
servidores están en las oficinas (para formación, visión 
de conferencias y presentaciones grabadas y similares), 
en los hoteles y en las instalaciones de producción de 
vídeo. 

23.4.3. Recuperación basada en la semejanza 

En muchas aplicaciones multimedia los datos sólo se 
describen en la base de datos de manera aproximada. 
Un ejemplo son los datos de huellas dactilares del Apar¬ 
tado 23.4. Otros ejemplos son: 

• Datos gráficos. Dos gráficos o imágenes que sean 
ligeramente diferentes en su representación en la 
base de datos pueden ser considerados iguales por 
un usuario. Por ejemplo, una base de datos puede 
almacenar diseños de marcas comerciales. Cuan¬ 
do haya que registrar una nueva marca puede que 
el sistema necesite identificar antes todas las mar¬ 
cas parecidas que se registraron anteriormente. 

• Datos de sonido. Se están desarrollando interfa¬ 
ces de usuario basadas en el reconocimiento de la 
voz que permiten a los usuarios dar un comando 
o identificar un elemento de datos por la voz. Debe 
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comprobarse la semejanza de la entrada del usua¬ 
rio con los comandos o los elementos de datos 
almacenados en el sistema. 

• Datos manuscritos. La entrada manuscrita pue¬ 
de utilizarse para identificar un elemento de datos 
manuscrito o una orden manuscrita almacenados 
en la base de datos. Una vez más, se necesita com¬ 
probar la semejanza. 

El concepto de semejanza suele ser subjetivo y espe¬ 
cífico del usuario. No obstante, la verificación de la 


semejanza suele tener más éxito que el reconocimien¬ 
to de voz o de letras manuscritas, ya que la entrada pue¬ 
de compararse con datos que ya se hallan en el sistema 
y, por tanto, el conjunto de opciones disponibles para 
el sistema es limitado. 

Hay varios algoritmos para hallar las mejores coin¬ 
cidencias con una entrada dada mediante la comproba¬ 
ción de la semejanza. Algunos sistemas, incluidos un 
sistema telefónico de llamada por nombre activado por 
la voz, se han distribuido comercialmente. Véanse las 
notas bibliográficas para hallar más referencias. 


23.5. COMPUTADORAS PORTÁTILES Y BASES DE DATOS PERSONALES 


Las bases de datos comerciales de gran tamaño se han 
almacenado tradicionalmente en las instalaciones infor¬ 
máticas centrales. En las aplicaciones de bases de datos 
distribuidas ha habido generalmente una fuerte admi¬ 
nistración central de las bases de datos y de la red. Dos 
tendencias tecnológicas se han combinado para crear 
aplicaciones en las cuales la suposición de un control y 
de una administración centrales no es completamente 
correcta: 

1. El uso cada vez más extendido de computadoras 
personales y, sobre todo, de computadoras portá¬ 
tiles. 

2. El desarrollo de una infraestructura inalámbrica 
de comunicaciones digitales de coste relativa¬ 
mente bajo, basada en redes inalámbricas de área 
local, redes celulares de paquetes digitales y otras 
tecnologías. 

La informática móvil se ha demostrado útil en 
muchas aplicaciones. Muchos profesionales viajeros 
utilizan computadoras portátiles para poder trabajar y 
tener acceso a los datos durante el viaje. Los servicios 
de mensajería utilizan computadoras portátiles para ayu¬ 
dar al seguimiento de los paquetes. Los servicios de 
emergencia utilizan computadoras portátiles en el esce¬ 
nario de los desastres, en las emergencias médicas y 
similares para tener acceso a la información y para intro¬ 
ducir datos relativos a la situación. Siguen surgiendo 
nuevas aplicaciones de las computadoras portátiles. 

Las computadoras comunicadas por radio crean una 
situación en que las máquinas ya no tienen ubicaciones 
fijas ni direcciones de red. Las consultas dependien¬ 
tes de la ubicación son una clase interesante de con¬ 
sultas que está motivada por las computadoras portáti¬ 
les; en estas consultas la ubicación del usuario 
(computadora) es un parámetro de la consulta. El valor 
del parámetro de ubicación lo proporciona el usuario o, 
cada vez más, un sistema de posicionamiento global 
(GPS). Un ejemplo son los sistemas de información para 
viajeros que proporcionan a los conductores datos sobre 


los hoteles, los servicios de carretera y similares. El pro¬ 
cesamiento de las consultas sobre los servicios que se 
hallan más adelante en la ruta actual debe basarse en la 
ubicación del usuario, en su dirección de movimiento 
y en su velocidad. Se ofrecen cada vez más ayudas a la 
navegación como una característica integrada en los 
automóviles. 

La energía (la carga de las baterías) es un recurso 
escaso para la mayor parte de las computadoras portá¬ 
tiles. Esta limitación influye en muchos aspectos del 
diseño de los sistemas. Entre las consecuencias más inte¬ 
resantes de la necesidad de eficiencia energética está el 
empleo de emisiones programadas de datos para redu¬ 
cir la necesidad de transmisión de consultas de los sis¬ 
temas portátiles. 

Cantidades cada vez mayores de datos residen en 
máquinas administradas por los usuarios en lugar de por 
administradores de bases de datos. Además, estas máqui¬ 
nas pueden estar, a veces, desconectadas de la red. En 
muchos casos hay un conflicto entre la necesidad del 
usuario de seguir trabajando mientras está desconecta¬ 
do y la necesidad de consistencia global de los datos. 
En los apartados 23.5.1 a 23.5.4 se estudian técnicas en 
uso y en desarrollo para tratar los problemas de las com¬ 
putadoras portátiles y de la informática personal. 

23.5.1. Un modelo de informática móvil 

El entorno de la informática móvil consiste en compu¬ 
tadoras portátiles, denominadas anfitriones móviles, y 
una red de computadoras conectadas por cable. Los anfi¬ 
triones móviles se comunican con la red de cable 
mediante computadoras denominadas estaciones para 
el soporte de movilidad. Cada estación para el sopor¬ 
te de movilidad gestiona los anfitriones móviles de su 
celda, es decir, del área geográfica que cubre. Los anfi¬ 
triones móviles pueden moverse de unas celdas a otras, 
por lo que necesitan el relevo del control de una esta¬ 
ción para el soporte de movilidad a otra. Dado que los 
anfitriones móviles pueden, a veces, estar apagados, un 
anfitrión puede abandonar una celda y aparecer más tar- 
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de en otra distante. Por tanto, los movimientos de unas 
celdas a otras no se realizan necesariamente entre cel¬ 
das adyacentes. Dentro de un área pequeña, como un 
edificio, los anfitriones móviles pueden conectarse 
mediante una red inalámbrica de área local que pro¬ 
porciona conectividad de coste más reducido que las 
redes celulares de área amplia, y que reduce la sobre¬ 
carga de entregas. 

Es posible que los anfitriones móviles se comuni¬ 
quen directamente sin intervención de ninguna estación 
para el soporte de movilidad. No obstante, esa comu¬ 
nicación sólo puede ocurrir entre anfitriones cercanos. 
Estas formas directas de comunicación se están hacien¬ 
do más frecuentes con la llegada del estándar Blueto- 
oth. Bluetooth utiliza radio digital de corto alcance para 
permitir la conectividad por radio a alta velocidad (has¬ 
ta 721 kilobits por segundo) a distancias inferiores a 
diez metros. Concebido inicialmente como una sustitu¬ 
ción de los cables, lo más prometedor de Bluetooth es 
la conexión ad hoc sencilla entre computadoras portá¬ 
tiles, PDAs, teléfonos celulares y las denominadas apli¬ 
caciones inteligentes. 

La infraestructura de red para la informática móvil 
consiste en gran parte en dos tecnologías: redes ina¬ 
lámbricas locales (como la red de área local Orinoco de 
Avaya) y redes de telefonía celular basadas en paque¬ 
tes. Los primeros sistemas celulares utilizaban tecno¬ 
logía analógica y estaban diseñados para la comunica¬ 
ción de voz. Los sistemas digitales de segunda 
generación siguieron centrándose en las aplicaciones de 
voz. Los sistemas de tercera generación (3G) y los deno¬ 
minados sistemas 2.5G utilizan redes basadas en paque¬ 
tes y están más adaptados a las aplicaciones de datos. 
En estas redes la voz es sólo una más de las aplicacio¬ 
nes (aunque una económicamente importante). 

Bluetooth, las redes de área local inalámbricas y las 
redes celulares 2.5G y 3G hacen posible que se comu¬ 
niquen a bajo coste gran variedad de dispositivos. Aun¬ 
que esta comunicación en sí misma no encaja en el 
dominio de las aplicaciones habituales de bases de datos, 
los datos de la contabilidad, del control y de la admi¬ 
nistración correspondientes a esta comunicación gene¬ 
ran bases de datos enormes. La inmediatez de la comu¬ 
nicación por radio genera la necesidad de acceso en 
tiempo real a muchas de estas bases de datos. Esta nece¬ 
sidad de inmediatez añade otra dimensión a las restric¬ 
ciones del sistema, un asunto que se abordará en pro¬ 
fundidad en el Apartado 24.3. 

El tamaño y las limitaciones de potencia de muchas 
computadoras portátiles han llevado a la creación de 
jerarquías de memoria alternativas. En lugar de, o ade¬ 
más de, el almacenamiento en disco, puede incluirse la 
memoria flash, que se estudió en el Apartado 11.1. Si el 
anfitrión móvil incluye un disco duro, puede que se per¬ 
mita que el disco deje de girar cuando no se utilice, para 
ahorrar energía. Las mismas consideraciones de tama¬ 
ño y de energía limitan el tipo y el tamaño de las pan¬ 
tallas utilizadas en los dispositivos portátiles. Los dise¬ 


ñadores de los dispositivos portátiles suelen crear inter¬ 
faces de usuario especiales para trabajar con estas res¬ 
tricciones. No obstante, la necesidad de presentar datos 
basados en la web ha exigido la creación de estándares 
para presentaciones. El protocolo de aplicaciones ina¬ 
lámbrico (Wireless Application Protocol, WAP) es un 
estándar para el acceso inalámbrico a internet. Los 
exploradores basados en WAP tienen acceso a páginas 
web especiales que utilizan el lenguaje de marcas ina¬ 
lámbrico (Wireless Markup Language, WML), un len¬ 
guaje basado en XML diseñado para las restricciones 
de la exploración web móvil e inalámbrica. 

23.5.2. Encaminamiento y procesamiento 
de consultas 

La mta entre cada par de anfitriones puede cambiar con 
el tiempo si alguno de los dos anfitriones es móvil. Este 
sencillo hecho tiene un efecto espectacular en el nivel 
de la red, puesto que las direcciones de red basadas en 
las ubicaciones ya no son constantes en el sistema. 

La informática móvil también afecta directamente al 
procesamiento de consultas de las bases de datos. Como 
se vio en el Capítulo 19, hay que considerar los costes 
de comunicación cuando se escoge una estrategia de 
procesamiento distribuido de las consultas. La infor¬ 
mática móvil hace que los costes de comunicación cam¬ 
bien de manera dinámica, lo que complica el proceso 
de optimización. Además, hay varios conceptos de cos¬ 
te que se deben considerar en relación con los demás: 

• El tiempo del usuario es una materia prima muy 
valiosa en muchas aplicaciones profesionales. 

• El tiempo de conexión es la unidad por la que se 
asignan los costes monetarios en algunos sistemas 
de telefonía celular. 

• El número de bytes, o de paquetes, transferidos 

es la unidad por la que se calculan los costes en 
algunos sistemas de telefonía celular digital. 

• Los costes basados en la hora del día varían, en 
función de si la comunicación se produce durante 
los periodos pico o durante los periodos valle. 

• La energía es limitada. A menudo la energía de las 
baterías es un recurso escaso cuyo uso debe opti¬ 
mizarse. Un principio básico de las comunicacio¬ 
nes inalámbricas es que hace falta menos energía 
para recibir señales de radio que para emitirlas. Así, 
la transmisión y la recepción de los datos imponen 
demandas de energía diferentes al anfitrión móvil. 

23.5.3. Datos de difusión 

Suele ser deseable para los datos que se solicitan con 
frecuencia que los transmitan las estaciones de soporte 
de las computadoras portátiles en un ciclo continuo, en 
lugar de que se transmitan a los anfitriones móviles a 
petición de éstos. Una aplicación típica de estos datos 
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de difusión es la información de las cotizaciones bur¬ 
sátiles. Hay dos motivos para utilizar los datos de difu¬ 
sión. En primer lugar, los anfitriones móviles evitan el 
coste energético de transmitir las solicitudes de datos. 
En segundo lugar, los datos de difusión pueden recibir¬ 
los simultáneamente gran número de anfitriones móvi¬ 
les, sin coste adicional. Por tanto, el bando de ancha dis¬ 
ponible para transmisiones se utiliza de manera más 
efectiva. 

Así, los anfitriones móviles pueden recibir los datos 
a medida que se transmiten, en lugar de consumir ener¬ 
gía transmitiendo solicitudes. Puede que los anfitriones 
móviles tengan almacenamiento no volátil disponible 
para guardar en la caché los datos de difusión para su 
empleo posterior. Dada una consulta, los anfitriones 
móviles pueden minimizar los costes energéticos deter¬ 
minando si pueden procesarla sólo con los datos guar¬ 
dados en la caché. Si los datos guardados en la caché 
son insuficientes, hay dos opciones: Esperar a que los 
datos se transmitan o transmitir una solicitud de datos. 
Para tomar esta decisión los anfitriones móviles deben 
conocer el momento en que se transmitirán los datos en 
cuestión. 

Los datos de difusión pueden transmitirse de acuer¬ 
do con una programación fija o según una programa¬ 
ción variable. En el primer caso, los anfitriones móvi¬ 
les utilizan la programación fija conocida para 
determinar el momento en que se transmitirán los datos 
en cuestión. En el segundo caso, se debe transmitir la 
propia programación de transmisiones en una frecuen¬ 
cia de radio conocida y a intervalos de tiempos conoci¬ 
dos. 

En efecto, el medio transmitido puede modelarse 
como un disco con una latencia elevada. Las solicitu¬ 
des de datos pueden considerarse atendidas cuando los 
datos solicitados se transmiten. Las programaciones de 
transmisión se comportan como los índices de los dis¬ 
cos. Las notas bibliográficas citan trabajos de investi¬ 
gación recientes en el área de administración de los datos 
de difusión. 

23.5.4. Desconexiones y consistencia 

Dado que puede que las comunicaciones inalámbricas 
se paguen con arreglo al tiempo de conexión, hay un 
incentivo para que se desconecten determinados anfi¬ 
triones móviles durante periodos de tiempo considera¬ 
bles. Las computadoras portátiles sin conectividad ina¬ 
lámbrica están desconectadas la mayor parte del tiempo 
en que se utilizan, excepto cuando se conectan de mane¬ 
ra periódica a sus computadoras anfitrionas, físicamen¬ 
te o mediante una red informática. 

Durante esos periodos de desconexión puede que el 
anfitrión móvil siga operativo. Puede que el usuario del 
anfitrión móvil formule consultas y solicite actualiza¬ 
ciones de los datos que residen localmente o que se han 
guardado en la caché local. Esta situación crea varios 
problemas, en especial: 


• Recuperabilidad: Las actualizaciones introduci¬ 
das en una máquina desconectada pueden perder¬ 
se si el anfitrión móvil sufre un fallo catastrófico. 
Dado que el anfitrión móvil representa un único 
punto de fallo, no se puede simular bien el alma¬ 
cenamiento estable. 

• Consistencia: Los datos guardados en la caché 
local pueden quedar obsoletos, pero el anfitrión 
móvil no puede descubrir la situación hasta que 
vuelva a conectarse. De manera parecida, las actua¬ 
lizaciones que se produzcan en el anfitrión móvil 
no pueden transmitirse hasta que se produzca la 
reconexión. 

El problema de la consistencia se exploró en el Capí¬ 
tulo 19, donde se estudiaron las particiones de la red, y 
aquí se partirá de esa base. En los sistemas distribuidos 
conectados por redes físicas las particiones se conside¬ 
ran un modo de fallo; en la informática móvil las parti¬ 
ciones mediante desconexiones son parte del modo de 
operación normal. Por tanto, es necesario permitir que 
continúe el acceso a los datos a pesar de las particiones, 
pese al riesgo de que se produzca una pérdida de con¬ 
sistencia. 

Para los datos actualizados sólo por el anfitrión móvil, 
es sencillo transmitir las actualizaciones cuando el anfi¬ 
trión móvil vuelve a conectarse. No obstante, si el anfi¬ 
trión móvil guarda en la caché copias de los datos sólo 
para lectura que pueden actualizar otras computadoras, 
puede que los datos guardados en la caché acaben sien¬ 
do inconsistentes. Cuando se conecta el anfitrión móvil, 
puede recibir informes de invalidación que lo informen 
de las entradas de la caché que están obsoletas. No obs¬ 
tante, cuando el anfitrión móvil esté desconectado puede 
perder algún informe de invalidación. Una solución sen¬ 
cilla a este problema es invalidar toda la caché al volver 
a conectar el anfitrión móvil, pero una solución tan extre¬ 
ma resulta muy costosa. En las notas bibliográficas se 
citan varios esquemas para el almacenamiento en la caché. 

Si se pueden producir actualizaciones tanto en el anfi¬ 
trión móvil como en el resto del sistema, la detección 
de las actualizaciones conflictivas resulta más difícil. 
Los esquemas basados en la numeración de versiones 
permiten las actualizaciones de los archivos comparti¬ 
dos desde los anfitriones desconectados. Estos esque¬ 
mas no garantizan que las actualizaciones sean consis¬ 
tentes. Más bien, garantizan que, si dos anfitriones 
actualizan de manera independiente la misma versión 
del documento, el conflicto se acabará descubriendo, 
cuando los anfitriones intercambien información direc¬ 
tamente o mediante un anfitrión común. 

El esquema del vector de versiones detecta las 
inconsistencias cuando las copias de un documento se 
actualizan de manera independiente. Este esquema per¬ 
mite que las copias de un documento se almacenen en 
varios anfitriones. Aunque se utilice el término docu¬ 
mento, el esquema puede aplicarse a otros elementos de 
datos, como las tupias de una relación. 
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La idea básica es que cada anfitrión i almacene, con 
su copia de cada documento d , un vector de versiones, 
es decir, un conjunto de números de versiones j V d ,[/j}, 
con una entrada para cada uno de los demás anfitriones 
j en los que se puede actualizar potencialmente el do¬ 
cumento. Cuando un anfitrión i actualiza un documen¬ 
to d, incrementa el número de versión V di [i] en una uni¬ 
dad. 

Siempre que dos anfitriones i y j se conectan entre 
sí, intercambian los documentos actualizados, de modo 
que los dos obtienen versiones nuevas de los docu¬ 
mentos. No obstante, antes de intercambiar los docu¬ 
mentos, los anfitriones tienen que averiguar si las copias 
son consistentes: 

1. Si los vectores de versiones son iguales en los dos 
anfitriones —es decir, si para cada k, V dl \k] = V d j 
[Aj— las copias del documento d son idénticas. 

2. Si, para cada k, V di [k] < V dj [£] y los vectores de 
versiones no son idénticos, la copia del documento 
d del anfitrión i es más antigua que la del anfitrión 
j. Es decir, la copia del documento d del anfitrión 
j se obtuvo mediante una o más modificaciones 
de la copia del documento del anfitrión i. El anfi¬ 
trión i sustituye su copia de d, así como su copia 
del vector de versiones de d, por las copias del 
anfitrión j. 

3. Si hay un par de anfitriones k y m tales que V dl [k] 
< V dj M y V’ í/( [>«j > V dj [m\, las copias son incon¬ 
sistentes ■; es decir, la copia de d de i contiene 
actualizaciones realizadas por el anfitrión k que 
no se han transmitido al anfitrión j y, de manera 
parecida, la copia de d de j contiene actualiza¬ 
ciones llevadas a cabo por el anfitrión m que no 
se han transmitido al anfitrión i. Entonces, las 
copias de d son inconsistentes, ya que se han rea¬ 
lizado de manera independiente dos o más actua¬ 
lizaciones de d. Puede que se necesite la inter¬ 
vención manual para mezclar las actualizaciones. 

El esquema de vectores de versiones se diseñó ini¬ 
cialmente para tratar los fallos en los sistemas de archi¬ 
vos distribuidos. El esquema adquirió mayor impor¬ 
tancia porque las computadoras portátiles suelen 
almacenar copias de los archivos que también se hallan 


presentes en los sistemas servidores, lo que constituye 
de facto un sistema de archivos distribuido que suele 
estar desconectado. Otra aplicaciones de este esquema 
son los sistemas en grupo, en que los anfitriones se 
conectan de manera periódica, en lugar de hacerlo de 
manera continua, y deben intercambiar los documentos 
actualizados. El esquema del vector de versiones tam¬ 
bién tiene aplicaciones en las bases de datos replicadas. 

No obstante, el esquema del vector de versiones no 
logra abordar el problema más difícil e importante que 
plantean las actualizaciones de los datos compartidos, 
la reconciliación de las copias inconsistentes de los 
datos. Muchas aplicaciones pueden llevar a cabo de 
manera automática la reconciliación ejecutando en cada 
computadora las operaciones que han conducido a las 
actualizaciones en las computadoras remotas durante el 
periodo de desconexión. Esta solución funciona si las 
operaciones de actualización conmutan, es decir, gene¬ 
ran el mismo resultado, independientemente del orden 
en que se ejecuten. Puede que se disponga de técnicas 
alternativas en ciertas aplicaciones; en el peor de los 
casos, no obstante, debe dejarse a los usuarios que 
resuelvan las inconsistencias. El tratamiento automáti¬ 
co de estas inconsistencias y la ayuda a los usuarios para 
que resuelvan las que no puedan tratarse de manera auto¬ 
mática sigue siendo un área de investigación. 

Otra debilidad es que el esquema del vector de ver¬ 
siones exige una comunicación sustancial entre el anfi¬ 
trión móvil que vuelve a conectarse y su estación para 
el soporte de movilidad. Las verificaciones de la con¬ 
sistencia pueden posponerse hasta que se necesiten los 
datos, aunque este retraso puede incrementar la incon¬ 
sistencia global de la base de datos. 

La posibilidad de desconexión y el coste de las comu¬ 
nicaciones inalámbricas limitan el aspecto práctico de 
las técnicas de procesamiento de las transacciones para 
los sistemas distribuidos estudiadas en el Capítulo 19. 
A menudo resulta preferible dejar que los usuarios pre¬ 
paren las transacciones en los anfitriones móviles y exi¬ 
gir que, en lugar de ejecutarlas localmente, las remitan 
al servidor para su ejecución. Las transacciones que 
afectan a más de una computadora y que incluyen un 
anfitrión móvil afrontan bloqueos de larga duración 
durante el compromiso de la transacción, a menos que 
las desconexiones sean raras o predecibles. 


23.6. RESUMEN 


El tiempo desempeña un papel importante en los sis¬ 
temas de bases de datos. Las bases de datos son mode¬ 
los del mundo real. Aunque la mayor parte de las bases 
de datos modelan el estado del mundo real en un 
momento dado (en el momento actual), las bases de 
datos temporales modelan los estados del mundo real 
a lo largo del tiempo. 


Los hechos de las relaciones temporales tienen 
momentos asociados cuando son válidos, que pueden 
representarse como una unión de intervalos. Los len¬ 
guajes de consulta temporales simplifican el modela¬ 
do del tiempo, así como las consultas relacionadas 
con el tiempo. 
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• Las bases de datos espaciales se utilizan cada vez más 
hoy en día para almacenar datos de diseño asistido 
por computadora y datos geográficos. 

• Los datos de diseño se almacenan sobre todo como 
datos vectoriales; los datos geográficos consisten en 
una combinación de datos vectoriales y lineales. Las 
restricciones de integridad espacial son importantes 
para los datos de diseño. 

• Los datos vectoriales pueden codificarse como datos 
de la primera forma normal o almacenarse mediante 
estructuras que no sean la primera forma normal, 
como las listas. Las estructuras de índices de finali¬ 
dad espacial resultan especialmente importantes para 
tener acceso a los datos espaciales y para procesar las 
consultas espaciales. 

• Los árboles R son una extensión multidimensional de 
los árboles B; con variantes como los árboles R + y los 
árboles R*, se han hecho populares en las bases de 
datos espaciales. Las estructuras de índices que divi¬ 
den el espacio de manera regular, como los árboles 
cuadráticos, ayudan a procesar las consultas de mez¬ 
cla espaciales. 


• Las bases de datos multimedia están aumentando de 
importancia. Problemas como la recuperación basa¬ 
da en la semejanza y la entrega de datos a velocida¬ 
des garantizadas son temas de investigación actuales. 

• Los sistemas de informática móvil se han vuelto de 
uso común, lo que ha llevado al interés por los siste¬ 
mas de bases de datos que pueden ejecutarse en ellos. 
El procesamiento de las consultas en estos sistemas 
puede implicar la búsqueda en las bases de datos de 
los servidores. El modelo de coste de las consultas 
debe contener el coste de la comunicación, incluido 
el coste monetario y el coste de la energía de las bate¬ 
rías, que resulta relativamente elevado para los siste¬ 
mas portátiles. 

• La transmisión resulta mucho más económica por recep¬ 
tor que la comunicación punto a punto, y la transmisión 
de datos como los datos bursátiles ayuda a los sistemas 
portátiles a recoger los datos de manera económica. 

• La operación en desconexión, el empleo de los datos 
de difusión y el almacenamiento de los datos en la 
caché son tres problemas importantes que se están 
abordando hoy en día en la informática móvil. 


TÉRMINOS DE REPASO 


• Árboles cuadráticos 

- Árbol cuadrático PR 

- Árbol cuadrático regional 

• Árboles k-d 

• Árboles k-d-B 

• Árboles R 

- Caja límite 

- División cuadrática 

• Bases de datos de diseño 

• Bases de datos multimedia 

• Consistencia 

- Esquema del vector de versiones 

- Informes de invalidación 

• Consultas dependientes de la ubicación 

• Consultas espaciales 

• Consultas de proximidad 

• Consultas regionales 

• Consultas de vecino más próximo 

• Datos de difusión 

• Datos de diseño asistido por computadora 
(Computer-Aided-Design, CAD) 

• Datos espaciales y geográficos 

• Datos geográficos 

• Datos isócronos 

• Datos por líneas (ráster) 

• Datos de medios continuos 


• Datos temporales 

• Datos vectoriales 

• Formatos de datos multimedia 

• Indexado de los datos espaciales 

• Informática móvil 

- Anfitriones móviles 

- Celda 

- Estaciones de soporte de las computadoras portá 
tiles 

- Relevo 

• Lenguajes de consulta temporales 

• Mezcla temporal 

• Proyección temporal 

• Recuperación basada en la semejanza 

• Relación bitemporal 

• Relación instantánea 

• Relación temporal 

• Reunión espacial 

• Selección temporal 

• Servidores de vídeo 

• Sistemas de información geográfica 

• Sistema de posicionamiento global (Global Positio 
ning System, GPS) 

• Tiempo de transacción 

• Tiempo universal coordinado (UTC) 

• Tiempo válido 

• Triangulación 
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EJERCICIOS 


23.1. Indíquense los dos tipos de tiempo y en lo que se dife¬ 
rencian. Indíquese el motivo de que haya dos tipos de 
tiempo asociados con cada tupia. 

23.2. Indíquese si se conservarán las dependencias funcio¬ 
nales si se convierte una relación en una relación tem¬ 
poral añadiéndole un atributo temporal. Indíquese el 
modo en que se resuelve el problema en las bases de 
datos temporales. 

23.3. Supóngase que se tiene una relación que contiene las 
coordenadas x, y y los nombres de varios restauran¬ 
tes. Supóngase también que las únicas consultas que 
se formularán serán de la forma siguiente: La consulta 
especifica un punto y pregunta si hay algún restau¬ 
rante exactamente en ese punto. Indíquese el tipo de 
índice que sería preferible, árbol R o árbol B. Indí- 
quese el motivo. 

23.4. Considérense dos datos vectoriales bidimensionales 
en que los elementos de datos no se solapan. Indíquese 
si es posible convertir esos datos vectoriales en datos 
lineales. En caso de que sea posible, indíquense los 
inconvenientes de almacenar los datos lineales obte¬ 
nidos de esa conversión en lugar de los datos vecto¬ 
riales originales. 

23.5. Supóngase que se dispone de una base de datos espa¬ 
cial que soporta consultas regionales (con regiones 
circulares) pero no consultas de vecino más próximo. 
Descríbase un algoritmo para hallar el vecino más pró¬ 
ximo haciendo uso de varias consultas regionales. 

23.6. Supóngase que se desean almacenar segmentos rec¬ 
tilíneos en un árbol R. Si un segmento rectilíneo no 
es paralelo a los ejes, su caja límite puede ser grande 
y contener una gran área vacía. 

• Descríbase el efecto en el rendimiento de tener cajas 
límite de gran tamaño en las consultas que piden los 
segmentos rectilíneos que intersectan una región 
dada. 

• Descríbase brevemente una técnica para mejorar el 
rendimiento de esas consultas y dese un ejemplo de 
sus ventajas. Consejo: Se pueden dividir los seg¬ 
mentos en partes más pequeñas. 

23.7. Dese un procedimiento recursivo para calcular de 
manera eficiente la mezcla espacial de dos relaciones 
con índices de árbol R. (Consejo: Utilícense cajas lími¬ 
te para comprobar si las entradas hojas bajo un par de 
nodos internos pueden intersectarse.) 

23.8. Estúdiese el soporte de los datos espaciales ofrecido 
por el sistema de bases de datos que se está utilizan¬ 
do e impleméntese lo siguiente: 

a. Un esquema para representar la ubicación geográ¬ 
fica de los restaurantes y características como la 


cocina que se sirve en cada restaurante y su nivel 
de precios. 

b. Una consulta para hallar los restaurantes econó¬ 
micos que sirven comida india y que se hallan a 
menos de nueve kilómetros de casa del lector 
(supóngase cualquier ubicación para la casa del lec¬ 
tor). 

c. Una consulta para hallar para cada restaurante su 
distancia al restaurante más cercano que sirve la 
misma cocina y con el mismo nivel de precios. 

23.9. Indíquense los problemas que se producen en un sis¬ 
tema de medios continuos si los datos se entregan 
demasiado lento o demasiado rápido. 

23.10. Descríbase el modo en que las ideas subyacentes a la 
organización RAID (Apartado 11.3) pueden utilizar¬ 
se en un entorno de datos de difusión, donde puede 
que haya ocasionalmente ruido que impida la recep¬ 
ción de parte de los datos que se están transmitiendo. 

23.11. Indíquense tres características principales de la infor¬ 
mática móvil en redes inalámbricas que son diferen¬ 
tes de las de los sistemas distribuidos tradicionales. 

23.12. Indíquense tres factores que haya que considerar en 
la optimización de las consultas para la informática 
móvil que no se consideren en los optimizadores de 
consultas tradicionales. 

23.13. Defínase un modelo en que se difundan repetidamente 
los datos en el que el medio de transmisión se mode¬ 
le como un disco virtual. Descríbase el modo en que 
el tiempo de acceso y la velocidad de transferencia de 
datos del disco virtual se diferencian de los valores 
correspondientes a un disco duro normal. 

23.14. Considérese una base de datos de documentos en la 
que todos los documentos se conserven en una base 
de datos central. En las computadoras portátiles se 
guardan copias de algunos documentos. Supóngase 
que la computadora portátil A actualiza una copia del 
documento 1 mientras está desconectada y que, al mis¬ 
mo tiempo, la computadora portátil B actualiza una 
copia del documento 2 mientras está desconectada. 
Muéstrese el modo en que el esquema del vector ver¬ 
sión puede asegurar la actualización adecuada de la 
base de datos central y de las computadoras portáti¬ 
les cuando se vuelva a conectar una computadora por¬ 
tátil. 

23.15. Dese un ejemplo para mostrar que el esquema del vec¬ 
tor versión no asegura la secuenciabilidad. (Consejo: 
Utilícese el ejemplo del Ejercicio 23.14, con la supo¬ 
sición de que los documentos 1 y 2 están disponibles 
en las dos computadoras portátiles A y B, y téngase 
en cuenta la posibilidad de que un documento pueda 
leerse sin que se actualice.) 
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NOTAS BIBLIOGRÁFICAS 


La incorporación del tiempo en el modelo relacional de 
datos se estudia en Snodgrass y Ahn [1985], Clifford y 
Tansel [1985], Gadia [1986], Gadia [1988], Snodgrass 
[1987], Tansel et al. [1993], Snodgrass et al. [1994] y 
Tuzhilin and Clifford [1990]. Stam y Snodgrass [1988] 
y Soo [1991] proporcionan estudios sobre la adminis¬ 
tración de los datos temporales. Jensen et al. [1994] pre¬ 
sentan un glosario de conceptos de las bases de datos 
temporales, con la intención de unificar la terminolo¬ 
gía, un propósito que tuvo un impacto significativo en 
el estándar SQL. Tansel et al. [1993] es una colección 
de artículos sobre diferentes aspectos de las bases de 
datos temporales. Chomicki [1995] presenta técnicas 
para administrar las restricciones para la integridad tem¬ 
poral. Un concepto de completitud para los lenguajes 
de consultas temporales análogo a la completitud rela¬ 
cional (equivalencia con el álgebra relacional) se da en 
Clifford et al. [1994], 

Samet [1995b] proporciona una introducción a la 
gran cantidad de trabajo realizado sobre las estructu¬ 
ras espaciales de índices. Samet [1990] proporciona 
una cobertura en el nivel de los libros de texto de las 
estructuras espaciales de datos. Una de las primeras 
descripciones de los árboles cuadráticos se proporcio¬ 
na en Finkel y Bentley [1974]. Samet [1990] y Samet 
[1995b] describen numerosas variantes de los árboles 
cuadráticos. Bentley [1975] describe los árboles k-d, y 
Robinson [1981] describe los árboles k-d-B. Los árbo¬ 
les R se presentaron originalmente en Guttman [1984]. 
Las extensiones de los árboles R se presentan en Sellis 
et al. [1987], que describen los árboles R + ; Beckmann 
et al. [1990], que describen el árbol R*; y Kamel y 
Faloutsos [1992], que describen una versión paralela 
de los árboles R. 

Brinkhoff et al. [1993] estudian una implementación 
de las mezclas espaciales mediante árboles R. Lo y 
Ravishankar [1996] y Patel y DeWitt [1996] presentan 
los métodos basados en las particiones para el cálculo 


de las mezclas espaciales. Samet y Aref [1995] propor¬ 
cionan una introducción de los modelos espaciales de 
datos, de las operaciones espaciales y de la integración 
de los datos espaciales con los no espaciales. El inde- 
xado de los documentos manuscritos se estudia en Aref 
et al. [1995b], Aref et al. [1995a] y Lopresti y Tomkins 
[1993]. Las mezclas de los datos aproximados se estu¬ 
dian en Barbará et al. [1992]. Evangelidis et al. [1995] 
presentan una técnica para el acceso concurrente a los 
índices de los datos espaciales. 

Samet [1995a] describe los campos de investigación 
en las bases de datos multimedia. El indexado de los 
datos multimedia se estudia en Faloutsos y Lin [1995]. 
Los servidores de vídeo se estudian en Anderson et al. 
[1992], Rangan et al. [1992], Ozden et al. [1994], 
Freedman y DeWitt [1995] y Ozden et al. [1996b]. La 
tolerancia a los fallos se estudia en Berson et al. [1995] 
y Ozden et al. [1996a]. Reason et al. [1996] sugieren 
esquemas alternativos de compresión para la transmi¬ 
sión de vídeo por redes inalámbricas. Las técnicas de 
administración del almacenamiento en disco para los 
datos de vídeo se describen en Chen et al. [1995], Cher- 
venak et al. [1995], Ozden et al. [1995a] y Ozden et al. 
[1995b], 

La administración de la información en los sistemas 
que incluyen computadoras portátiles se estudia en Alon¬ 
so y Korth [1993] y en Imielinski y Badrinath [1994]. 
Imielinski y Korth [1996] presentan una introducción a 
la informática móvil y una colección de trabajos de 
investigación sobre el tema. El indexado de los datos 
de difusión por medios inalámbricos se estudia en Bar¬ 
bará e Imielinski [1994] y en Acharya et al. [1995]. La 
administración de los discos en las computadoras por¬ 
tátiles se aborda en Douglis et al. [1994]. 

El esquema del vector de versiones para la detección 
de la inconsistencia en los sistemas de archivos distri¬ 
buidos se describe en Popek et al. [1981] y en Parker et 
al. [1983]. 
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CAPÍTULO 



PROCESAMIENTO AVANZADO 
DE TRANSACCIONES 


E n los Capítulos 15, 16 y 17 se introdujo el concepto de transacción, que es una unidad de 
programa que tiene acceso —y posiblemente actualiza— a varios elementos de datos, y 
cuya ejecución asegura la conservación de las propiedades AC1D. En esos capítulos se 
estudiaron gran variedad de esquemas para asegurar las propiedades ACID en entornos en los 
que pueden producirse fallos, y en los que las transacciones pueden ejecutarse de manera con¬ 
currente. 

En este capítulo se irá más allá de los esquemas básicos estudiados anteriormente y se abor¬ 
darán los conceptos del procesamiento avanzado de las transacciones, incluidos los monitores 
de procesamiento de transacciones, los flujos de trabajo de las transacciones, las bases de datos 
en memoria principal, las bases de datos en tiempo real, las transacciones de larga duración, las 
transacciones anidadas y las transacciones con varias bases de datos. 


24.1. MONITORES DE PROCESAMIENTO DE TRANSACCIONES 


Los monitores de procesamiento de transacciones 
(transaction-processing monitors, TP monitors) son 

sistemas que se desarrollaron en los años setenta y 
ochenta del siglo pasado, inicialmente como respuesta 
a la necesidad de soportar gran número de terminales 
remotas (como los terminales de reserva de las líneas 
aéreas) desde una sola computadora. El término TP 
monitor significaba inicialmente monitor de teleproce¬ 
samiento (Teleprocessing Monitor). 

Los monitores TP han evolucionado desde entonces 
para ofrecer el soporte central para el procesamiento 
distribuido de las transacciones, y el término monitor 
TP ha adquirido su significado actual. El monitor CICS 
TP de IBM fue uno de los primeros monitores TP, y se 
ha utilizado mucho. Entre los monitores TP de la gene¬ 
ración actual están Tuxedo y Top End (los dos actual¬ 
mente de BEA Systems), Encina (de Transare, que aho¬ 
ra forma parte de IBM) y Transaction Server (de 
Microsoft). 

24.1.1. Arquitecturas de los monitores TP 

Los sistemas de procesamiento de transacciones a gran 
escala se construyen en torno a una arquitectura clien¬ 
te-servidor. Una manera de crear estos sistemas es tener 
un proceso servidor para cada cliente; el servidor reali¬ 
za la autentificación, y luego ejecuta las acciones soli¬ 
citadas por el cliente. 

Este modelo de proceso por cliente se ilustra en la 
Figura 24.1. Este modelo presenta varios problemas con 
respecto a la utilización de la memoria y la velocidad 
de procesamiento: 


• Los requisitos de memoria para cada proceso son 
elevados. Aunque se comparta la memoria para el 
código de los programas entre todos los procesos, 
cada proceso consume memoria para los datos 
locales y los descriptores de los archivos abiertos, 
así como para la sobrecarga del sistema operativo, 
como las tablas de páginas para soportar la memo¬ 
ria virtual. 

• El sistema operativo divide el tiempo disponible 
de CPU entre los procesos conmutando entre ellos; 
esta tarea se denomina multitarea. Cada cambio 
de contexto entre un proceso y el siguiente supone 
una sobrecarga considerable de la CPU; incluso en 
los sistemas rápidos de hoy en día un cambio de 
contexto puede tardar cientos de microsegundos. 

Los problemas anteriores pueden evitarse teniendo 
un proceso con un solo servidor al que se conecten todos 
los servidores; este modelo se denomina modelo de ser¬ 
vidor único, ilustrado en la Figura 24.1b. Los clientes 
remotos envían las solicitudes al proceso del servidor, 
que ejecuta entonces esas solicitudes. Este modelo tam¬ 
bién se utiliza en los entornos cliente-servidor, en los 
que los clientes envían solicitudes a un proceso de un 
solo servidor. El proceso servidor asume las tareas, como 
la autentificación de los usuarios, que normalmente asu¬ 
miría el sistema operativo. Para evitar bloquear otros 
clientes al procesar una solicitud de larga duración de 
un cliente, el servidor tiene varias hebras: El proceso 
servidor tiene una hebra de control para cada cliente y, 
en efecto, implementa su propia multitarea de baja sobre¬ 
carga. Ejecuta el código en nombre de un cliente duran- 
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remotos 

(a) Modelo de proceso por cliente 



(c) Modelo de muchos servidores y un solo encamlnador 
FIGURA 24.1. Arquitecturas de los monitores TP. 


te un rato, luego guarda el contexto interno y conmuta 
al código de otro cliente. A diferencia de la sobrecarga 
de la multitarea, el coste de la conmutación entre hebras 
es reducido (generalmente sólo unos pocos microse- 
gundos). 

Los sistemas basados en el modelo de servidor úni¬ 
co, como la versión original del monitor TP C1CS de 
IBM y los servidores de archivos como NetWare de 
Novell, proporcionaban con éxito tasas de transaccio¬ 
nes elevadas con recursos limitados. No obstante, tenían 
problemas, especialmente cuando varias aplicaciones 
tenían acceso a la misma base de datos: 

• Dado que todas las aplicaciones se ejecutan como 
un único proceso, no hay protección entre ellas. 
Un fallo en una aplicación puede afectar también 
a todas las demás aplicaciones. Sería mejor ejecu¬ 
tar cada aplicación como un proceso separado. 

• Estos sistemas no están adecuados a las bases de 
datos paralelas o distribuidas, ya que un proceso 
servidor no puede ejecutarse simultáneamente en 
varios servidores (sin embargo, las hebras concu¬ 
rrentes de un proceso pueden soportarse en un sis¬ 
tema multiprocesador de memoria compartida). Se 
trata de un inconveniente serio para las organiza¬ 
ciones de gran tamaño en las que el procesamien¬ 
to paralelo resulta fundamental para el tratamien¬ 
to de grandes cargas de trabajo, y los datos 
distribuidos son cada vez más frecuentes. 



remotos 


(b) Modelo de servidor único 



(d) Modelo de muchos servidores y muchos encamlnadores 


Una manera de resolver estos problemas es ejecutar 
varios procesos del servidor de aplicaciones que tengan 
acceso a una base de datos común y dejar que los clien¬ 
tes se comuniquen con la aplicación mediante un úni¬ 
co proceso de comunicaciones que encamine las soli¬ 
citudes. Este modelo se denomina modelo de varios 
servidores y un solo encaminador, ilustrado en la Figu¬ 
ra 24.1c. Este modelo soporta procesos de servidor inde¬ 
pendientes para varias aplicaciones; además, cada apli¬ 
cación puede tener un grupo de procesos de servidor, 
cualquiera de los cuales puede manejar una sesión clien¬ 
te. La solicitud puede, por ejemplo, encaminarse al ser¬ 
vidor con carga menor de un grupo. Como antes, cada 
proceso de servidor puede tener, a su vez, varias hebras, 
de modo que puede atender de manera concurrente 
varios clientes. Como generalización adicional, los ser¬ 
vidores de aplicaciones pueden ejecutarse en sitios dife¬ 
rentes de una base de datos paralela o distribuida y el 
proceso de comunicaciones puede manejar las comuni¬ 
caciones entre los procesos. 

La arquitectura anterior también se utiliza mucho en 
los servidores web. Un servidor web tiene un proceso 
principal que recibe las solicitudes HTTP, y luego asig¬ 
na la tarea de manejar cada solicitud a un proceso dife¬ 
rente (escogido de entre un grupo de procesos). Cada 
uno de los procesos tiene, a su vez, varias hebras, por 
lo que puede atender varias solicitudes. 

Una arquitectura más general tiene varios procesos, 
en lugar de uno solo, para comunicarse con los clien- 
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tes. Los procesos de comunicación con los clientes inte¬ 
ractúan con uno o varios procesos encaminadores, que 
encaminan las solicitudes hacia el servidor correspon¬ 
diente. Los monitores TP de generaciones posteriores, 
por tanto, tienen una arquitectura diferente, denomina¬ 
da modelo de varios servidores y varios encamina¬ 
dores, ilustrado en la Figura 24. Id. Un proceso con¬ 
trolador inicia los demás procesos y supervisa su 
funcionamiento. Pathway de Tándem es un ejemplo de 
los monitores TP de generaciones posteriores que utili¬ 
zan esta arquitectura. Los sistemas servidores web de 
rendimiento muy elevado también adoptan una arqui¬ 
tectura de este tipo. 

La estructura detallada de un monitor TP aparece en 
la Figura 24.2. Un monitor TP hace más cosas que pasar 
mensajes a los servidores de aplicaciones. Cuando lle¬ 
gan los mensajes, puede que haya que ubicarlos en una 
cola; por tanto, hay un gestor de colas para los mensa¬ 
jes entrantes. Puede que la cola sea una cola durade¬ 
ra, cuyas entradas sobreviven a los fallos del sistema. 
El empleo de colas duraderas ayuda a asegurar que se 
acaben procesando los mensajes una vez recibidos y 
guardados en la cola, independientemente de los fallos 
del sistema. La gestión de las autorizaciones y de los 
servidores de aplicaciones (por ejemplo, el inicio de los 
servidores y el encaminamiento de los mensajes hacia 
los servidores) son otras funciones de los monitores TP. 
Los monitores TP suelen proporcionar recursos para la 
elaboración de registros históricos, recuperación y con¬ 


trol de concurrencia, lo que permite a los servidores de 
aplicaciones implementar directamente, si fuera nece¬ 
sario, las propiedades ACID de las transacciones. 

Finalmente, los monitores TP también proporcionan 
soporte para la mensajería persistente. Hay que recor¬ 
dar que la mensajería persistente (Apartado 19.4.3) pro¬ 
porciona una garantía de que el mensaje se entregue si 
(y sólo si) la transacción se compromete. 

Además de estos servicios, muchos monitores TP 
también proporcionaban recursos para presentaciones 
para crear interfaces de menús o de formularios o para 
los clientes no inteligentes como los terminales; estos 
recursos ya no son importantes porque los clientes no 
inteligentes ya no se utilizan mucho. 

24.1.2. Coordinación de las aplicaciones 
mediante los monitores TP 

Hoy en día las aplicaciones suelen tener que interactuar 
con varias bases de datos. Puede que tengan que inte¬ 
ractuar con sistemas heredados, como los sistemas de 
almacenamiento de finalidad especial construidos direc¬ 
tamente con base en los sistemas de archivos. Final¬ 
mente, puede que tengan que comunicarse con usuarios 
o con otras aplicaciones en sitios remotos. Por tanto, 
también tienen que interactuar con subsistemas de comu¬ 
nicaciones. Es importante poder coordinar los accesos 
a los datos e implementar las propiedades ACID de las 
propiedades a través de esos sistemas. 




FIGURA 24.2. Componentes de los monitores TP. 
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Los monitores TP modernos proporcionan soporte 
para la construcción y la gestión de aplicaciones de un 
tamaño tan grande, creadas a partir de varios subsiste¬ 
mas como las bases de datos, los sistemas heredados y 
los sistemas de comunicaciones. Los monitores TP tra¬ 
tan cada subsistema como un gestor de recursos que 
proporciona acceso transaccional a algún conjunto de 
recursos. La interfaz entre el monitor TP y el gestor de 
recursos se define mediante un conjunto de primitivas 
de las transacciones como begin transacion (iniciar 
transacción), committransaction (comprometer tran¬ 
sacción), abort transaction (abortar transacción) y pre¬ 
pare _to commit transaction (preparar para compro¬ 
meter transacción, para el compromiso de dos fases). 
Por supuesto, el gestor de recursos también debe pro¬ 
porcionar otros servicios, como proporcionar datos, a 
la aplicación. 

La interfaz del gestor de recursos está definida por 
el estándar de procesamiento de transacciones distri¬ 
buidas X/Open. Muchos sistemas de bases de datos 
soportan los estándares X/Open, y pueden actuar como 
gestores de recursos. Los monitores TP —así como otros 
productos, como los sistemas SQL, que soportan los 
estándares X/Open— pueden conectarse con los gesto¬ 
res de recursos. 

Además, los servicios proporcionados por los moni¬ 
tores TP, como la mensajería persistente y las colas dura¬ 
deras, actúan como gestores de recursos que soportan 
las transacciones. Los monitores TP pueden actuar como 
coordinadores de los compromisos de dos fases para las 
transacciones que tienen acceso a estos servicios y a los 
sistemas de bases de datos. Por ejemplo, cuando se eje¬ 
cuta una transacción de actualización encolada, se entre¬ 
ga un mensaje y se elimina la transacción solicitada de 
la cola de solicitudes. El compromiso de dos fases entre 
la base de datos y los gestores de recursos para las colas 
duraderas y para la mensajería persistente ayuda a ase¬ 
gurar que, independientemente de los fallos, pueden 
producirse todas estas acciones o ninguna de ellas. 

También se pueden utilizar los monitores TP para 
administrar los sistemas complejos cliente-servidor que 


consisten en varios servidores y gran número de clien¬ 
tes. El monitor TP coordina las actividades como los 
puntos de control y los cierres del sistema. Proporcio¬ 
na la seguridad y la autentificación de los clientes. Admi¬ 
nistra los grupos de servidores añadiendo o eliminando 
servidores sin ninguna interrupción del sistema. Final¬ 
mente, controla el ámbito de los fallos. Si falla algún 
servidor, el monitor TP puede detectar ese fallo, abor¬ 
tar las transacciones en curso y reiniciarlas. Si falla algún 
nodo, el monitor TP puede migrar las transacciones a 
servidores de otros nodos y, una vez más, cancelar las 
transacciones incompletas. Cuando los nodos que fallan 
se reinician, el monitor TP puede gobernar la recupera¬ 
ción de los gestores de recursos del nodo. 

Los monitores TP pueden utilizarse para ocultar fallos 
de las bases de datos en los sistemas replicados; los sis¬ 
temas remotos de copia de seguridad (Apartado 17.10) 
son un ejemplo de sistemas replicados. Las solicitudes 
de transacciones se remiten al monitor TP, que trans¬ 
fiere los mensajes a una de las réplicas de la base de 
datos (al sitio principal, en el caso de sistemas remotos 
de copia de seguridad). Si falla algún sitio, el monitor 
TP puede encaminar los mensajes de manera transpa¬ 
rente hacia un sitio de copia de seguridad, enmasca¬ 
rando el fallo del primer sitio. 

En los sistemas cliente-servidor los clientes suelen 
interactuar con los servidores mediante un mecanismo 
de llamada a procedimientos remotos (Remote-Pro- 
cedure Cali, RPC), en el que el cliente realiza la lla¬ 
mada a un procedimiento, que se ejecuta realmente en 
el servidor, y los resultados se devuelven al cliente. En 
lo relativo al código cliente que invoca al RPC, la lla¬ 
mada tiene el mismo aspecto que la invocación a un pro¬ 
cedimiento local. Los sistemas de monitores TP, como 
Encina, proporcionan una interfaz para RPC transac- 
cionales con sus servicios. En esta interfaz el mecanis¬ 
mo RPC proporciona llamadas que pueden utilizarse 
para encerrar una serie de llamadas RPC dentro de una 
transacción. Por tanto, las actualizaciones llevadas a cabo 
por el RPC se ejecutan dentro del ámbito de la transac¬ 
ción y se pueden hacer retroceder si hay algún fallo. 


24.2. FLUJOS DE TRABAJO DE TRANSACCIONES 


Un flujo de trabajo es una actividad en la que varias 
entidades de procesamiento ejecutan varias tareas de 
manera coordinada. Una tarea define un trabajo que 
hay que hacer y puede especificarse de varias maneras, 
incluidos una descripción textual en un archivo o en un 
mensaje de correo electrónico, un formulario, un men¬ 
saje o un programa de computadora. La entidad de pro¬ 
cesamiento que lleva a cabo las tareas puede ser una 
persona o un sistema de software (por ejemplo, un sis¬ 
tema de envío de correo electrónico, un programa de 
aplicación o un sistema gestor de bases de datos). 


La Figura 24.3 muestra ejemplos de flujos de traba¬ 
jo. Un ejemplo sencillo es el de un sistema de correo 
electrónico. La entrega de un solo mensaje de correo 
implica varios sistemas de envío de correo que reciben 
y transmiten el mensaje de correo, hasta que el mensa¬ 
je alcance su destino, donde se almacena. Cada sistema 
de envío de correo lleva a cabo una tarea —transmitir 
el mensaje al siguiente sistema de envío de correo— y 
puede ser necesaria la tarea de varios sistemas de envío 
de correo para encaminar el mensaje desde su origen 
hasta su destino. Otros términos empleados en la lite- 


592 





CAPÍTULO 24 PROCESAMIENTO AVANZADO DE TRANSACCIONES 


Aplicación de flujo de trabajo 

Tarea típica 

Entidad de procesamiento típica 

encaminamiento de correo electrónico 
procesamiento de préstamos 
procesamiento de órdenes de compra 

mensaje de correo electrónico 
procesamiento de formularios 
procesamiento de formularios 

sistemas de envío de correo electrónico 
seres humanos, software de aplicaciones 
seres humanos, software de aplicaciones, SGBD 


FIGURA 24.3. Ejemplos de flujos de trabajo. 


ratura de bases de datos y similares para hacer referen¬ 
cia a los flujos de trabajo son flujo de tareas y aplica¬ 
ciones multisistema. Las tareas del flujo de trabajo a 
veces se denominan pasos. 

En general, los flujos de trabajo pueden implicar a 
una o varias personas. Por ejemplo, considérese el pro¬ 
cesamiento de un préstamo. El flujo de trabajo corres¬ 
pondiente aparece en la Figura 24.4. La persona que 
desea un préstamo rellena un formulario, que es revi¬ 
sado por el encargado de los préstamos. Un empleado 
que procesa las solicitudes de préstamos comprueba los 
datos del formulario, utilizando fuentes como las ofici¬ 
nas de referencia de préstamo. Cuando se ha reunido 
toda la información solicitada, el encargado de los prés¬ 
tamos puede que decida conceder el préstamo; puede 
que esa decisión tenga que ser aprobada por uno o más 
empleados de rango superior, después de lo cual se podrá 
conceder el préstamo. Cada persona de este flujo de tra¬ 
bajo realiza una tarea; en un banco que no tenga auto¬ 
matizada la tarea de procesamiento de los préstamos, la 
coordinación de las tareas suele ejecutarse pasando la 
solicitud del préstamo con notas y otra información 
adjuntas de un empleado al siguiente. Otros ejemplos 
de flujos de trabajo son el procesamiento de notas de 
gastos, de órdenes de compra y de transacciones de tar¬ 
jetas de préstamo. 

Hoy en día es más probable que toda la información 
relativa a un flujo de trabajo se almacene en forma digi¬ 
tal en una o más computadoras y, con el auge de las 
redes, la información puede transferirse con facilidad 
de una computadora a otra. Por tanto, es viable que las 
organizaciones automaticen sus flujos de trabajo. Por 
ejemplo, para automatizar las tareas implicadas en el 


procesamiento de los préstamos, se puede almacenar la 
solicitud de préstamo y la información asociada en una 
base de datos. El propio flujo de trabajo implica, enton¬ 
ces, la transferencia de la responsabilidad de una per¬ 
sona a la siguiente y, posiblemente, incluso a progra¬ 
mas que pueden capturar de manera automática la 
información necesaria. Las personas implicadas pueden 
coordinar sus actividades mediante el correo electróni¬ 
co, por ejemplo. 

Hay que abordar dos actividades, en general, para 
automatizar un flujo de trabajo. La primera es la espe¬ 
cificación del flujo de trabajo: detallar las tareas que 
hay que ejecutar y definir los requisitos de la ejecución. 
El segundo problema es la ejecución del flujo de tra¬ 
bajo, que hay que llevar a cabo mientras se proporcio¬ 
nan las salvaguardas de los sistemas tradicionales de 
bases de datos relativas a corrección de los cálculos e 
integridad y durabilidad de los datos. Por ejemplo, no 
resulta aceptable que se pierda una solicitud de présta¬ 
mo o una nota, ni que se procese más de una vez, debi¬ 
do a un fallo del sistema. La idea subyacente a los flu¬ 
jos de trabajo transaccionales es utilizar y ampliar los 
conceptos de las transacciones al contexto de los flujos 
de trabajo. 

Las dos actividades se complican por el hecho de 
que muchas organizaciones utilizan varios sistemas de 
procesamiento de la información administrados de 
manera independiente que, en la mayor parte de los 
casos, se desarrollaron por separado para automatizar 
funciones diferentes. Puede que las actividades del flu¬ 
jo de trabajo exijan interacciones entre varios de esos 
sistemas, cada uno de las cuales lleva a cabo una tarea, 
así como interacciones con las personas. 



FIGURA 24.4. Flujo de trabajo en el procesamiento de préstamos. 
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En los últimos años se han desarrollado varios sis¬ 
temas de flujo de trabajo. Aquí se estudiarán las pro¬ 
piedades de los sistemas de flujo de trabajo en un nivel 
relativamente abstracto, sin descender a los detalles de 
ningún sistema concreto. 

24.2.1. Especificación del flujo de trabajo 

No hace falta modelar los aspectos intemos de cada tarea 
con vistas a la especificación y gestión de un flujo de 
trabajo. En una vista abstracta de las tareas, cada tarea 
puede utilizar los parámetros almacenados en sus varia¬ 
bles de entrada, recuperar y actualizar los datos del sis¬ 
tema local, almacenar los resultados en sus variables de 
salida y se la puede consultar sobre su estado de ejecu¬ 
ción. En cualquier momento de la ejecución el estado 
del flujo de trabajo consiste en el conjunto de estados 
de las tareas constituyentes del flujo de trabajo, y los 
estados (valores) de todas las variables de la especifi¬ 
cación del flujo de trabajo. 

La coordinación de las tareas puede especificarse de 
manera estadística o dinámica. La especificación estáti¬ 
ca define las tareas —y las dependencias entre ellas— 
antes de que comience la ejecución del flujo de trabajo. 
Por ejemplo, las tareas del flujo de trabajo de las notas 
de gastos pueden consistir en la aprobación de las notas 
por una secretaria, un gestor y un contable, en ese orden, 
y, finalmente, en la entrega de un cheque. Las depen¬ 
dencias entre las tareas puede ser sencilla —hay que com¬ 
pletar cada tarea antes de que comience la siguiente. 

Una generalización de esta estrategia es la imposi¬ 
ción de una condición previa a la ejecución de cada tarea 
del flujo de trabajo, de modo que todas las tareas posi¬ 
bles del flujo de trabajo y sus dependencias se conoz¬ 
can por anticipado, pero que sólo se ejecuten aquellas 
tareas cuyas condiciones previas se satisfagan. Las con¬ 
diciones previas pueden definirse mediante dependen¬ 
cias como las siguientes: 

• El estado de ejecución de otras tareas, por ejem¬ 
plo, «la tarea t¡ no puede comenzar hasta que la 
tarea t ¡haya finalizado», o «la tarea t¡ debe abor¬ 
tarse si la tarea t¡ se ha comprometido». 

• Los resultados de otras tareas, por ejemplo, «la 
tarea f ; puede comenzar si la tarea í- devuelve un 
valor mayor que veinticinco», o «la tarea de apro¬ 
bación por el gestor puede comenzar si la tarea de 
aprobación por la secretaria devuelve el resultado 
de Aceptar». 

• Las variables externas modificadas por los even¬ 
tos extemos, por ejemplo, «la tarea t¡ no puede ini¬ 
ciarse antes de las nueve de la mañana», o «la tarea 
t¡ debe iniciarse antes de que transcurran veinti¬ 
cuatro horas desde la finalización de la tarea tj». 

Las dependencias pueden combinarse mediante los 
conectores lógicos (or, and, not) para formar condi¬ 
ciones previas complejas de planificación. 


Un ejemplo de la planificación dinámica de las ta¬ 
reas son los sistemas de encaminamiento del correo elec¬ 
trónico. La tarea que hay que programar a continuación 
para cada mensaje de correo depende de la dirección de 
destino de ese mensaje y de los encaminadores inter¬ 
medios que se hallan en funcionamiento. 

24.2.2. Requisitos de atomicidad ante fallos 
de los flujos de trabajo 

El diseñador del flujo de trabajo puede especificar los 
requisitos de atomicidad ante fallos del flujo de tra¬ 
bajo de acuerdo con la semántica del flujo de trabajo. 
El concepto tradicional de atomicidad ante fallos exige 
que el fallo de cualquier tarea dé lugar al fallo del flu¬ 
jo de trabajo. Sin embargo, un flujo de trabajo puede, 
en muchos casos, sobrevivir al fallo de una de sus tare¬ 
as, por ejemplo, ejecutando una tarea funcionalmente 
equivalente en otro sitio. Por consiguiente, se debe per¬ 
mitir al diseñador que defina los requisitos de atomici¬ 
dad ante fallos del flujo de trabajo. El sistema debe 
garantizar que cada ejecución de un flujo de trabajo ter¬ 
mine en un estado que satisfaga los requisitos de ato¬ 
micidad ante fallos definidos por el diseñador. Esos esta¬ 
dos se denominan estados aceptables de terminación 
del flujo de trabajo. Todos los demás estados del flujo 
de trabajo constituyen un conjunto de estados de ter¬ 
minación no aceptables, en los que puede que se vio¬ 
len los requisitos de atomicidad de los fallos. 

Los estados aceptables de terminación pueden decla¬ 
rarse comprometidos o abortados. Un estado acepta¬ 
ble de terminación comprometido es un estado de eje¬ 
cución en el que los objetivos del flujo de trabajo se han 
conseguido. Por el contrario, un estado aceptable de 
terminación abortado es un estado válido de termina¬ 
ción en el que el flujo de trabajo no ha logrado alcan¬ 
zar sus objetivos. Si se ha alcanzado un estado acepta¬ 
ble de terminación abortado hay que deshacer todos los 
efectos indeseables de la ejecución parcial del flujo de 
trabajo de acuerdo con los requisitos de atomicidad ante 
fallos del flujo de trabajo. 

El flujo de trabajo debe alcanzar un estado acepta¬ 
ble de terminación incluso en caso de fallo del sistema. 
Por tanto, si el flujo de trabajo se hallaba en un estado 
no aceptable de terminación en el momento del fallo, 
durante la recuperación del sistema hay que llevarlo a 
un estado aceptable de terminación (bien sea abortado, 
bien comprometido). 

Por ejemplo, en el flujo de trabajo del procesamien¬ 
to de los préstamos, en el estado final, o bien se comu¬ 
nica al solicitante del préstamo que no se le puede con¬ 
ceder, o se le abona el importe solicitado. En caso de 
fallo como puede ser un fallo de larga duración del sis¬ 
tema de verificación, puede devolverse la solicitud de 
préstamo al solicitante con una explicación adecuada; 
este resultado constituiría una terminación abortada 
aceptable. Una terminación comprometida aceptable 
sería la aceptación o el rechazo de la solicitud. 
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En general, las tareas pueden comprometer y liberar 
sus recursos antes de que el flujo de trabajo alcance un 
estado de terminación. Sin embargo, si la transacción 
multitarea aborta posteriormente, su atomicidad ante 
fallos puede que exija que se deshagan todos los efec¬ 
tos de las tareas ya completadas (por ejemplo, las sub¬ 
transacciones comprometidas) ejecutando tareas com¬ 
pensadoras (como las subtransacciones). La semántica 
de la compensación exige que la transacción compen¬ 
sadora acabe completando su ejecución con éxito, qui¬ 
zás tras varios reenvíos. 

En el flujo de trabajo del procesamiento de las notas 
de gastos, por poner un ejemplo, puede que se reduz¬ 
ca el importe del presupuesto del departamento debi¬ 
do a la aprobación inicial de una nota de gastos por el 
gestor. Si posteriormente se rechaza esa nota, debido a 
un fallo o por otro motivo, puede que haya que restau¬ 
rar el presupuesto mediante una transacción compen¬ 
sadora. 

24.2.3. Ejecución de los flujos de trabajo 

La ejecución de las tareas puede controlarla un coordi¬ 
nador humano o un sistema de software denominado 
sistema gestor de flujos de trabajo. Los sistemas ges¬ 
tores de flujos de trabajo consisten en un planificador, 
los agentes para las tareas y un mecanismo para con¬ 
sultar el estado del sistema del flujo de trabajo. Cada 
agente de tarea controla la ejecución de una tarea por 
una entidad de procesamiento. El planificador es un pro¬ 
grama que procesa los flujos de trabajo remitiendo dife¬ 
rentes tareas para su ejecución, controlando los dife¬ 
rentes eventos y evaluando las condiciones relativas a 
las dependencias entre las tareas. El planificador puede 
remitir una tarea para su ejecución (a un agente de tare¬ 
as) o solicitar que se aborte una tarea previamente remi¬ 
tida. En el caso de las transacciones con varias bases de 
datos, las tareas son subtransacciones y las entidades de 
procesamiento son sistemas gestores de bases de datos 
locales. De acuerdo con las especificaciones del flujo 
de trabajo, el planificador hace que se cumplan las 
dependencias de planificación y es responsable de ase¬ 
gurar que las tareas alcancen estados aceptables de ter¬ 
minación. 

Hay tres enfoques arquitectónicos del desarrollo de 
los sistemas gestores de flujos de trabajo. La arquitec¬ 
tura centralizada tiene un solo planificador que pro¬ 
grama las tareas de todos los flujos de trabajo que se 
ejecutan de manera concurrente. La arquitectura par¬ 
cialmente distribuida tiene un planificador para cada 
flujo de trabajo. Cuando los problemas de la ejecución 
concurrente pueden separarse de la función de planifi¬ 
cación, esta opción es una elección natural. La arqui¬ 
tectura completamente distribuida no tiene planifi¬ 
cador, pero los agentes de tareas coordinan su ejecución 
comunicándose entre sí para satisfacer las dependen¬ 
cias entre las tareas y otros requisitos de ejecución del 
flujo de trabajo. 


Los sistemas de ejecución de flujos de trabajo siguen 
el enfoque totalmente distribuido que se acaba de des¬ 
cribir y están basados en la mensajería. La mensajería 
puede implementarse mediante mecanismos de mensa¬ 
jería persistente. Algunas implementaciones utilizan el 
correo electrónico para la mensajería; estas implemen¬ 
taciones proporcionan muchas de las características de 
la mensajería persistente, pero generalmente no garan¬ 
tizan la atomicidad de la entrega de los mensajes y el 
compromiso de las transacciones. Cada sitio tiene un 
agente de tareas que ejecuta las tareas recibidas median¬ 
te los mensajes. Puede que la ejecución también impli¬ 
que la entrega de mensajes a personas, que tienen que 
llevar a cabo alguna acción. Cuando se completa una 
tarea en un sitio y hay que procesarla en otro sitio, el 
agente de tareas transmite un mensaje al sitio siguien¬ 
te. El mensaje contiene toda la información relevante 
sobre la tarea que hay que realizar. Estos sistemas de 
flujos de trabajo basados en mensajes resultan espe¬ 
cialmente útiles en las redes que se pueden desconec¬ 
tar durante parte del tiempo, como las redes de acceso 
telefónico. 

El enfoque centralizado se utiliza en sistemas de flu¬ 
jos de trabajo en que los datos se almacenan en una base 
de datos central. El planificador notifica a los diferen¬ 
tes agentes, como pueden ser las personas o los pro¬ 
gramas informáticos, que hay que llevar a cabo una tarea 
y realiza un seguimiento de su finalización. Resulta más 
sencillo realizar un seguimiento del estado del flujo de 
trabajo con el enfoque centralizado que con el enfoque 
completamente distribuido. 

El planificador debe garantizar que termine el flu¬ 
jo de trabajo en uno de los estados aceptables de ter¬ 
minación especificados. Idealmente, antes de intentar 
ejecutar un flujo de trabajo, el planificador debe exa¬ 
minarlo para comprobar si puede terminar en un esta¬ 
do no aceptable. Si el planificador no puede garanti¬ 
zar que el flujo de trabajo termine en un estado 
aceptable, debe rechazar esas especificaciones sin inten¬ 
tar ejecutar el flujo de trabajo. Por ejemplo, considé¬ 
rese un flujo de trabajo consistente en dos tareas repre¬ 
sentadas por las subtransacciones Si y S 2 , con los 
requisitos de atomicidad ante fallos que indican que se 
deben comprometer las dos subtransacciones o ningu¬ 
na de ellas. Si Sj y S 2 no proporcionan estados prepa¬ 
rados para comprometerse (para un compromiso de dos 
fases) y, además, no tienen transacciones compensa¬ 
doras, es posible alcanzar un estado en que se com¬ 
prometa una subtransacción y se aborte la otra, y no 
haya manera de llevar a las dos al mismo estado. Por 
tanto, esa especificación del flujo de trabajo es inse¬ 
gura, y debe rechazarse. 

Los controles de seguridad como el que se acaba de 
describir pueden ser imposibles o poco prácticos de 
implementar en el planificador; pasa a ser, entonces, res¬ 
ponsabilidad de la persona que diseña la especificación 
del flujo de trabajo asegurarse de que el flujo de traba¬ 
jo sea seguro. 
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24.2.4. Recuperación de los flujos de trabajo 

El objetivo de la recuperación de los flujos de traba¬ 
jo es hacer que se cumpla la atomicidad ante fallos de 
los flujos de trabajo. Los procedimientos de recupera¬ 
ción deben asegurarse de que, si se produce un fallo en 
cualquiera de los componentes de procesamiento del flu¬ 
jo de trabajo (incluido el planificador), éste acabe alcan¬ 
zando un estado aceptable de terminación (sea abortado 
o comprometido). Por ejemplo, el planificador puede 
continuar procesando tras el fallo y la recuperación, como 
si no hubiera pasado nada, lo que proporciona recupe- 
rabilidad hacia delante. En caso contrario, el planifica¬ 
dor puede abortar todo el flujo de trabajo (es decir, alcan¬ 
zar uno de los estados globales abortados). De cualquier 
forma, puede que haga falta comprometer algunas sub¬ 
transacciones o incluso remitirlas para su ejecución (por 
ejemplo, las subtransacciones compensadoras). 

Se da por supuesto que las entidades de procesa¬ 
miento implicadas en el flujo de trabajo tienen sus pro¬ 
pios sistemas locales de recuperación y tratan sus fallos 
locales. Para recuperar el contexto del entorno de eje¬ 
cución las ratinas de recuperación de los fallos deben 
restaurar la información de estado del planificador en 
el momento del fallo, incluida la información sobre el 
estado de ejecución de cada tarea. Por tanto, la infor¬ 
mación de estado correspondiente debe registrarse en 
almacenamiento estable. 

También hay que considerar el contenido de las colas 
de mensajes. Cuando un agente transfiere una tarea a 
otro, la transferencia debe ejecutarse exactamente una 
vez: si la transferencia tiene lugar dos veces, puede que 
se ejecute dos veces una tarea; si no se produce la trans¬ 
ferencia, puede que se pierda la tarea. La mensajería 
persistente (Apartado 19.4.3) proporciona exactamen¬ 
te las características para asegurar una transferencia 
positiva y única. 


24.2.5. Sistemas gestores de flujos de trabajo 

Los flujos de trabajo suelen codificarse a mano como 
parte de los sistemas de aplicaciones. Por ejemplo, los 
sistemas de planificación de los recursos de las empre¬ 
sas (enterprise resource planning, ERP), que ayudan a 
coordinar las actividades en toda la empresa, tienen 
incorporados numerosos flujos de trabajo. 

El objetivo de los sistemas gestores de flujos de tra¬ 
bajo es simplificar la construcción de flujos de trabajo 
y hacerlos más dignos de confianza, permitiéndoles que 
se especifiquen en un modo de nivel elevado y se eje¬ 
cuten de acuerdo con la especificación. Hay gran núme¬ 
ro de sistemas comerciales de gestión de flujos de datos; 
algunos, como FlowMark de IBM, son sistemas gesto¬ 
res de flujos de trabajo de propósito general, mientras 
que otros son específicos de flujos de trabajo concretos, 
como los sistemas de procesamiento de órdenes o los 
sistemas de comunicación de fallos. 

En el mundo actual de organizaciones interconecta¬ 
das, no es suficiente gestionar los flujos de trabajo exclu¬ 
sivamente en el interior de una organización. Los flu¬ 
jos de trabajo que atraviesan las fronteras organizativas 
se están volviendo cada vez más frecuentes. Por ejem¬ 
plo, considérese un pedido realizado por una organiza¬ 
ción y comunicado a otra organización que lo atiende. 
En cada organización puede que haya un flujo de tra¬ 
bajo asociado con el pedido, y es importante que los flu¬ 
jos de trabajo puedan operar entre sí con objeto de mini¬ 
mizar la intervención humana. 

La Coalición de gestión de flujos de trabajo (Work- 
flow Management Coalition) ha desarrollado estánda¬ 
res para la interoperatividad entre sistemas de flujos de 
trabajo. Los esfuerzos actuales de normalización utili¬ 
zan XML como lenguaje subyacente para comunicar la 
información sobre el flujo de trabajo. Véanse las notas 
bibliográficas para obtener más información. 


24.3. BASES DE DATOS EN MEMORIA PRINCIPAL 


Para peimitir una velocidad elevada de procesamiento 
de transacciones (centenares o millares de transaccio¬ 
nes por segundo) hay que utilizar hardware de alto ren¬ 
dimiento y aprovechar el paralelismo. Estas técnicas, 
por sí solas, no obstante, resultan insuficientes para obte¬ 
ner tiempos de respuesta muy bajos, ya que las opera¬ 
ciones de E/S de disco siguen constituyendo un cuello 
de botella: se necesitan alrededor de diez milisegundos 
para cada operación de E/S y esta cifra no se ha redu¬ 
cido a una velocidad comparable con el aumento en la 
velocidad de los procesadores. Las operaciones de E/S 
suelen ser el cuello de botella de las operaciones de lec¬ 
tura y de los compromisos de las transacciones. La ele¬ 
vada latencia de los discos (alrededor de diez milise¬ 
gundos de promedio) no sólo aumenta el tiempo 
necesario para tener acceso a un elemento de datos, sino 


que también limita el número de accesos por segundo. 

Se puede hacer un sistema de bases de datos menos 
ligado a los discos aumentando el tamaño de la memo¬ 
ria intermedia de la base de datos. Los avances en la 
tecnología de la memoria principal permiten construir 
memorias principales de gran tamaño con un coste rela¬ 
tivamente bajo. Hoy en día los sistemas comerciales de 
sesenta y cuatro bits pueden soportar memorias princi¬ 
pales de decenas de gigabytes. 

Para algunas aplicaciones, como el control en tiem¬ 
po real, es necesario almacenar los datos en la memo¬ 
ria principal para cumplir los requisitos de rendimien¬ 
to. El tamaño de memoria exigido para la mayoría de 
estos sistemas no resulta excepcionalmente grande, aun¬ 
que hay unas cuantas aplicaciones que exigen que sean 
residentes en la memoria varios gigabytes de datos. 
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Dado que el tamaño de la memoria ha estado crecien¬ 
do con una velocidad muy elevada, se puede esperar 
que un número creciente de aplicaciones tenga datos 
que quepan en la memoria principal. 

Las memorias principales de gran tamaño permiten 
el procesamiento más rápido de las transacciones, ya 
que los datos están residentes en la memoria. No obs¬ 
tante, sigue habiendo limitaciones relacionadas con los 
discos: 

• Hay que guardar en almacenamiento estable los 
registros del registro histórico antes de compro¬ 
meter una transacción. El rendimiento mejorado 
que hace posible la memoria principal de gran 
tamaño puede hacer que el proceso de registro se 
convierta en un cuello de botella. Se puede redu¬ 
cir el tiempo de compromiso creando un búfer de 
registro estable en la memoria principal, utilizan¬ 
do RAM no volátil (implementada, por ejemplo, 
mediante memoria sustentada por baterías). La 
sobrecarga impuesta por el registro también pue¬ 
de reducirse mediante la técnica de compromiso 
en grupo estudiada más adelante en este apartado. 
La productividad (el número de transacciones por 
segundo) sigue estando limitada por la velocidad 
de transferencia de datos del disco de registro. 

• Sigue habiendo que escribir los bloques de la 
memoria intermedia marcados como modificados 
por las transacciones comprometidas para que se 
reduzca la cantidad de registro histórico que hay 
que volver a ejecutar en el momento de la recupe¬ 
ración. Si la velocidad de actualización es extre¬ 
madamente elevada, la velocidad de transferencia 
de los datos al disco puede convertirse en un cue¬ 
llo de botella. 

• Si el sistema falla, se pierde toda la memoria prin¬ 
cipal. En la recuperación el sistema tiene la memo¬ 
ria intermedia de la base de datos vacía y hay que 
introducir desde el disco los elementos de datos 
cuando se tenga acceso a ellos. Por tanto, incluso 
una vez que esté completa la recuperación hace 
falta algo de tiempo antes de que se cargue com¬ 
pletamente la base de datos en memoria principal 
y se pueda reanudar el procesamiento de transac¬ 
ciones de alta velocidad. 

Por otro lado, las bases de datos en memoria princi¬ 
pal ofrecen oportunidades para la optimización: 

• Como la memoria resulta más costosa que el espa¬ 
cio de disco, hay que diseñar las estmcturas inter¬ 
nas de los datos de la memoria principal para redu¬ 
cir los requisitos de espacio. No obstante, las 
estmcturas de datos pueden tener punteros que atra¬ 
viesen varias páginas a diferencia de los de las 
bases de datos en disco, en las que el coste de que 
la operación de E/S atraviese varias páginas resul¬ 
taría excesivamente elevado. Por ejemplo, las 


estmcturas arbóreas de las bases de datos en memo¬ 
ria principal pueden ser relativamente profundas, 
a diferencia de los árboles B + , pero deben mini¬ 
mizar los requisitos de espacio. 

• No hace falta clavar en la memoria las páginas de 
la memoria intermedia antes de que se tenga acce¬ 
so a los datos, ya que las páginas de la memoria 
intermedia no se sustituyen nunca. 

• Las técnicas de procesamiento deben diseñarse 
para minimizar la sobrecarga de espacio, de modo 
que no se superen los límites de la memoria mien¬ 
tras se evalúa una consulta; esa situación daría lugar 
a que se paginara el área de intercambio y ralenti¬ 
zaría el procesamiento de la consulta. 

• Una vez eliminado el cuello de botella de las ope¬ 
raciones de E/S del disco, pueden convertirse en 
cuellos de botella operaciones como los bloqueos 
y los pestillos. Hay que eliminar estos cuellos de 
botella mediante mejoras en la implementación de 
estas operaciones. 

• Los algoritmos de recuperación pueden optimi¬ 
zarse, ya que rara vez hace falta borrar las páginas 
para hacer sitio a otras páginas. 

TimesTen y DataBlitz son dos productos de bases de 
datos en memoria principal que aprovechan varias de es¬ 
tas optimizaciones, mientras que la base de datos 
de Oracle ha añadido características especiales para 
soportar memorias principales de tamaño muy grande. 
Se da información adicional sobre las bases de datos en 
memoria principal en las referencias de las notas biblio¬ 
gráficas. 

El proceso de comprometer una transacción T exige 
que estos registros se escriban en almacenamiento esta¬ 
ble: 

• Todos los registros del registro histórico asociados 
con T que no se hayan remitidos al almacenamiento 
estable. 

• El registro < T comprometida > del registro his¬ 
tórico. 

Estas operaciones de salida suelen exigir la salida de 
bloques que sólo se hallan parcialmente llenos. Para ase¬ 
gurarse de que se saquen bloques casi llenos se utiliza 
la técnica de compromiso en grupo. En lugar de inten¬ 
tar comprometer T cuando se complete T, el sistema 
espera hasta que se hayan completado varias transac¬ 
ciones, o hasta que haya pasado un determinado perio¬ 
do de tiempo desde que se completó la ejecución de una 
transacción. Luego compromete el grupo de transac¬ 
ciones que están esperando, todas juntas. Los bloques 
escritos en el registro histórico en almacenamiento esta¬ 
ble contienen registros de varias transacciones. Median¬ 
te una cuidadosa selección del tamaño del grupo y del 
tiempo máximo de espera, el sistema puede asegurarse 
de que los bloques estén llenos cuando se escriben en 
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el almacenamiento estable sin hacer que las transac¬ 
ciones esperen demasiado. Esta técnica da como resul¬ 
tado, en promedio, menos operaciones de salida por 
cada transacción comprometida. 

Aunque el compromiso en grupo reduce la sobre¬ 
carga impuesta por el registro histórico, da lugar a un 
ligero retraso en el compromiso de las transacciones 
que llevan a cabo actualizaciones. El retraso puede 
hacerse bastante pequeño (del orden de diez milise- 
gundos), lo que resulta aceptable para muchas aplica¬ 


ciones. Estos retrasos pueden eliminarse si los discos o 
los controladores de disco soportan los búferes de RAM 
no volátil para las operaciones de escritura. Las tran¬ 
sacciones pueden comprometerse en cuanto la opera¬ 
ción de escritura se lleva a cabo en la memoria inter¬ 
media de RAM no volátil. En este caso, no hay 
necesidad de compromiso en grupo. 

Obsérvese que el compromiso en grupo resulta útil 
incluso en bases de datos con datos residentes en 
disco. 


24.4. SISTEMAS DE TRANSACCIONES DE TIEMPO REAL 


Las restricciones de integridad que se han considerado 
hasta ahora corresponden a los valores almacenados en 
la base de datos. En determinadas aplicaciones las res¬ 
tricciones incluyen tiempos límite en los que se tiene 
que haber completado una tarea. Entre estas aplicacio¬ 
nes están la gestión de factorías, el control del tráfico y 
la planificación. Cuando se incluyen tiempos límite, la 
corrección de la ejecución ya no es exclusivamente un 
problema de consistencia de la base de datos. Por el con¬ 
trario, hay que preocuparse por el número de tiempos 
límite sobrepasados y por el tiempo que hace que se 
sobrepasaron. Los tiempos límite se caracterizan de la 
manera siguiente: 

• Tiempo límite estricto. Pueden producirse pro¬ 
blemas graves, como fallos del sistema, si no se 
completa una tarea antes de su tiempo límite. 

• Tiempo límite firme. La tarea no tiene ningún 
valor si se completa después del tiempo límite. 

• Tiempo límite flexible. La tarea tiene un valor 
decreciente si se completa tras el tiempo límite, y 
el valor se aproxima a cero a medida que aumen¬ 
ta el retraso. 

Los sistemas con tiempos límite se denominan sistemas 
de tiempo real. 

La gestión de transacciones en los sistemas de tiem¬ 
po real debe tener en cuenta los tiempos límite. Si el 
protocolo de control de concurrencia determina que la 
transacción T¡ debe esperar, puede hacer que T¡ supere 
el tiempo límite. En esos casos, puede que resulte pre¬ 
ferible adelantar la transacción que mantiene el bloqueo 
y permitir que T siga adelante. El adelantamiento debe 
utilizarse con cuidado, no obstante, ya que el tiempo 
perdido por la transacción adelantada (debido al retro¬ 
ceso y al reinicio) puede hacer que la transacción supe¬ 
re su tiempo límite. Por desgracia, es difícil determinar 
si es preferible retroceder o esperar en una situación 
dada. 

Una de las principales dificultades para soportar las 
restricciones de tiempo real surge de la variabilidad en 


el tiempo de ejecución de las transacciones. En el caso 
más favorable, todos los accesos a los datos hacen refe¬ 
rencia a datos de la memoria intermedia de la base de 
datos. En el peor de los casos, cada acceso hace que se 
escriba una página de la memoria intermedia en el dis¬ 
co (precedida de los registros del registro histórico nece¬ 
sario), seguido de la lectura desde el disco de la página 
que contiene los datos a los que hay que tener acceso. 
Como los dos o más accesos al disco necesarios en el 
peor de los casos tardan varios órdenes de magnitud 
más que las referencias a la memoria principal necesa¬ 
rias en el caso más favorable, el tiempo de ejecución de 
las transacciones puede estimarse con muy poca preci¬ 
sión si los datos están residentes en el disco. Por tanto, 
se suelen utilizar las bases de datos en memoria princi¬ 
pal si hay que cumplir restricciones de tiempo real. 

Sin embargo, aunque los datos estén residentes en la 
memoria principal, la variabilidad del tiempo de ejecu¬ 
ción surge de las esperas de los bloqueos, de los abor¬ 
tos de las transacciones, etcétera. Los investigadores 
han dedicado esfuerzos considerables al control de con¬ 
currencia para las bases de datos de tiempo real. Han 
ampliado los protocolos de bloqueo para conceder una 
prioridad más elevada a las transacciones con tiempos 
límite más próximas. Han hallado que los protocolos de 
concurrencia optimistas tienen un buen comportamien¬ 
to en las bases de datos de tiempo real; es decir, estos 
protocolos dan lugar a menos tiempos límite sobrepa¬ 
sados incluso que los protocolos de bloqueo ampliados. 
Las notas bibliográficas proporcionan referencias para 
la investigación en el área de las bases de datos de tiem¬ 
po real. 

En los sistemas de tiempo real, los tiempos límite, y 
no la velocidad absoluta, son el aspecto más importan¬ 
te. El diseño de sistemas de tiempo real implica asegu¬ 
rarse de que hay suficiente capacidad de procesamien¬ 
to como para respetar las tiempos límite sin necesitar 
excesivos recursos de hardware. La consecución de este 
objetivo, pese a la variabilidad de los tiempos de eje¬ 
cución resultante de la gestión de las transacciones, sigue 
constituyendo un problema sin resolver. 
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24.5. TRANSACCIONES DE LARGA DURACIÓN 


El concepto de transacción se desarrolló inicialmente 
en el contexto de las aplicaciones de procesamiento de 
datos, en el que la mayor parte de las transacciones son 
de corta duración y no interactivas. Aunque las técni¬ 
cas presentadas aquí y, anteriormente, en los Capítulos 
15, 16 y 17 funcionan bien en esas aplicaciones, surgen 
problemas graves cuando se aplica este concepto a sis¬ 
temas de bases de datos que implican la interacción con 
personas. Esas transacciones tienen las siguientes pro¬ 
piedades principales: 

• Larga duración. Una vez que una persona inte¬ 
ractúa con una transacción activa esa transacción 
se transforma en una transacción de larga dura¬ 
ción desde la perspectiva de la computadora, ya 
que el tiempo de respuesta de las personas es len¬ 
to en comparación con la velocidad de las com¬ 
putadoras. Además, en las aplicaciones de diseño, 
la actividad humana puede suponer horas, días o 
periodos incluso más prolongados. Por tanto, las 
transacciones pueden ser de larga duración en tér¬ 
minos humanos, además de serlo en términos de 
la máquina. 

• Exposición de datos no comprometidos. Los 

datos generados y mostrados a los usuarios por las 
transacciones de larga duración no están compro¬ 
metidos, ya que la transacción puede abortarse. Por 
tanto, los usuarios —y, en consecuencia, las demás 
transacciones— pueden verse forzados a leer datos 
no comprometidos. Si varios usuarios están cola¬ 
borando en un proyecto puede que las transaccio¬ 
nes de los usuarios necesiten intercambiar datos 
antes de comprometer las transacciones. 

• Subtareas. Cada transacción interactiva puede 
consistir en un conjunto de subtareas iniciadas por 
el usuario. Puede que el usuario desee abortar una 
subtarea sin hacer necesariamente que aborte toda 
la transacción. 

• Recuperabilidad. Resulta inaceptable abortar una 
transacción interactiva de larga duración debido a 
un fallo del sistema. La transacción activa debe 
recuperarse hasta un estado que existiera poco antes 
del fallo para que se pierda una cantidad de traba¬ 
jo humano relativamente pequeña. 

• Rendimiento. El buen rendimiento de los siste¬ 
mas interactivos de transacciones se define como 
tiempo de respuesta rápido. Esta definición difie¬ 
re de la de los sistemas no interactivos, en los que 
el objetivo es una productividad (número de tran¬ 
sacciones por segundo) elevada. Los sistemas con 
productividad elevada hacen un uso eficiente de 
los recursos del sistema. Sin embargo, en el caso 
de las transacciones interactivas, el recurso más 


costoso es el usuario. Si hay que optimizar la efi¬ 
ciencia y la satisfacción del usuario, el tiempo de 
respuesta debe ser rápido (desde el punto de vista 
humano). En los casos en los que una tarea tarda 
mucho tiempo, el tiempo de respuesta debe ser pre¬ 
decible (es decir, la variabilidad de los tiempos de 
respuesta debe ser baja), de modo que los usuarios 
puedan administrar bien su tiempo. 

En los Apartados 24.5.1 a 24.5.5 se verá el motivo de 
que estas cinco propiedades sean incompatibles con 
las técnicas presentadas hasta ahora, y se estudiará el 
modo en que se pueden modificar esas técnicas para 
acomodar las transacciones interactivas de larga dura¬ 
ción. 

24.5.1. Ejecuciones no secuenciables 

Las propiedades que se han estudiado hacen poco prác¬ 
tico obligar a que se cumpla el requisito empleado en 
los capítulos anteriores de que sólo se permitan las pla¬ 
nificaciones secuenciables. Cada uno de los protocolos 
de control de concurrencia del Capítulo 16 tiene efec¬ 
tos negativos sobre las transacciones de larga duración: 

• Bloqueo de dos fases. Cuando no se puede con¬ 
ceder un bloqueo, la transacción que lo ha solici¬ 
tado se ve obligada a esperar a que se desbloquee 
el elemento de datos en cuestión. La duración de 
la espera es proporcional a la duración de la tran¬ 
sacción que sostiene el bloqueo. Si el elemento de 
datos está bloqueado por una transacción de corta 
duración, se espera que el tiempo de espera sea 
breve (excepto en el caso de interbloqueos o de 
carga extraordinaria del sistema). Sin embargo, si 
el elemento de datos está bloqueado por una tran¬ 
sacción de larga duración, la espera será prolon¬ 
gada. Los tiempo de espera elevados provocan 
tiempos de respuesta mayores y una mayor posi¬ 
bilidad de interbloqueos. 

• Protocolos basados en grafos. Los protocolos 
basados en grafos permiten que se liberen los blo¬ 
queos antes que con los protocolos de bloqueo de 
dos fases, y evitan los interbloqueos. Sin embar¬ 
go, imponen una ordenación de los elementos de 
datos. Las transacciones deben bloquear los ele¬ 
mentos de datos de manera consistente con esta 
ordenación. En consecuencia, puede que una tran¬ 
sacción tenga que bloquear más datos de los que 
necesita. Además, la transacción debe mantener 
el bloqueo hasta que no haya posibilidades de que 
se vuelva a necesitar. Por tanto, es probable que 
se produzcan esperas por bloqueos de larga dura¬ 
ción. 
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• Protocolos basados en las marcas temporales. 

Los protocolos de marcas temporales nunca nece¬ 
sitan que las transacciones esperen. Sin embargo, 
exigen que las transacciones se aborten bajo cier¬ 
tas circunstancias. Si se aborta una transacción de 
larga duración, se pierde una cantidad sustancial 
de trabajo. Para las transacciones no interactivas 
este trabajo perdido supone un problema de ren¬ 
dimiento. Para las transacciones interactivas el 
problema también es de satisfacción de los usua¬ 
rios. Resulta muy poco deseable que el usuario 
descubra que se han deshecho varias horas de tra¬ 
bajo. 

• Protocolos de validación. Al igual que los proto¬ 
colos basados en las marcas temporales, los proto¬ 
colos de validación hacen que se cumpla la secuen- 
cialidad mediante el aborto de transacciones. 

Por tanto, parece que el cumplimiento de la secuencia- 
lidad provoca esperas de larga duración, el aborto de 
transacciones de larga duración o ambas cosas. Hay 
resultados teóricos, citados en las notas bibliográficas, 
que sustentan esta conclusión. 

Surgen dificultades adicionales con el cumplimien¬ 
to de la secuencialidad cuando se consideran los pro¬ 
blemas de las recuperaciones. Ya se ha estudiado el pro¬ 
blema de los retrocesos en cascada, en los que el aborto 
de una transacción puede conducir al aborto de otras 
transacciones. Este fenómeno no es deseable, especial¬ 
mente para las transacciones de larga duración. Si se 
utiliza el bloqueo, se deben mantener bloqueos exclu¬ 
sivos hasta el final de la transacción, si hay que evitar 
el retroceso en cascada. Este mantenimiento de bloqueos 
exclusivos, no obstante, aumenta la duración del tiem¬ 
po de espera de las transacciones. 

Por tanto, parece que el cumplimiento de la atomi¬ 
cidad de las transacciones debe llevar a una mayor pro¬ 
babilidad de las esperas de larga duración o a crear la 
posibilidad de retrocesos en cascada. 

Estas consideraciones son la base de los conceptos 
alternativos de corrección de las ejecuciones concu¬ 
rrentes y de la recuperación de transacciones que se con¬ 
siderarán en el resto de este apartado. 

24.5.2. Control de concurrencia 

El objetivo fundamental del control de concurrencia de 
las bases de datos es asegurarse de que la ejecución con¬ 
currente de las transacciones no da lugar a una pérdida 
de la consistencia de la base de datos. El concepto de 
secuencialidad puede utilizarse para conseguir este obje¬ 
tivo, ya que todas las planificaciones secuenciables con¬ 
servan la consistencia de las bases de datos. No obs¬ 
tante, no todas las planificaciones que conservan la 
consistencia de las bases de datos son secuenciables. 
Por ejemplo, considérese nuevamente una base de datos 
bancaria que consista en dos cuentas, Ay B, con el requi¬ 
sito de consistencia de que se conserve la suma A + B. 


T, 

U 

leer(/t) 

A --A-50 
escribir(A) 

leer(B) 

B:=B- 10 
escribirte?) 

leer(5) 

B--B + 50 
escribir(5) 

leer(A) 

A :=A+ 10 
escribir(A) 


FIGURA 24.5. Planificación no secuenciable en cuanto a con¬ 
flictos. 

Aunque la planificación de la Figura 24.5 no es secuen¬ 
ciable para conflictos, pese a todo, conserva la suma de 
A + B. También ilustra dos aspectos importantes del 
concepto de corrección sin secuencialidad. 

• La corrección depende de las restricciones de con¬ 
sistencia concretas de la base de datos. 

• La corrección depende de las propiedades de las 
operaciones llevadas a cabo por cada transacción. 

En general, no es posible llevar a cabo un análisis auto¬ 
mático de las operaciones de bajo nivel de las transac¬ 
ciones y comprobar su efecto en las restricciones de 
consistencia de la base de datos. Sin embargo, hay téc¬ 
nicas más sencillas. Una de ellas es el empleo de las res¬ 
tricciones de consistencia de la base de datos como base 
de una división de la base de datos en subbases de datos 
en las que se puede administrar por separado la concu¬ 
rrencia. Otra es el intento de tratar algunas operaciones 
aparte de leer y de escribir como operaciones funda¬ 
mentales de bajo nivel y ampliar el control de concu¬ 
rrencia para trabajar con ellas. 

Las notas bibliográficas hacen referencia a otras téc¬ 
nicas para asegurar la consistencia sin exigir secuen¬ 
cialidad. Muchas de estas técnicas aprovechan varie¬ 
dades del control de concurrencia multiversión (véase 
el Apartado 17.6). A las aplicaciones de procesamiento 
de datos más antiguas que sólo necesitan una versión 
los protocolos multiversión les imponen una elevada 
sobrecarga de espacio para almacenar las versiones adi¬ 
cionales. Dado que muchas de las nuevas aplicaciones 
de bases de datos exigen el mantenimiento de las ver¬ 
siones de los datos, las técnicas de control de concu¬ 
rrencia que aprovechan varias versiones resultan prác¬ 
ticas. 

24.5.3. Transacciones anidadas y multinivel 

Las transacciones de larga duración pueden conside¬ 
rarse como conjuntos de subtareas relacionadas o sub¬ 
transacciones. Al estructurar cada transacción como 
un conjunto de subtransacciones, se puede mejorar el 
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paralelismo, ya que puede que sea posible ejecutar en 
paralelo varias subtransacciones. Además, es posible 
trabajar con los fallos de las subtransacciones (debi¬ 
dos a abortos, fallos del sistema, etcétera) sin tener 
que hacer retroceder toda la transacción de larga dura¬ 
ción. 

Una transacción anidada o multinivel T consiste en 
un conjunto T = { t v t 2 ,. .., t n ¡ de subtransacciones y en 
un orden parcial P sobre T. Cada subtransacción t¡ de T 
puede abortar sin obligar a que T aborte. En lugar de 
eso, puede que T reinicie t¡ o simplemente escoja no eje¬ 
cutar t¡. Si se compromete t¡, esa acción no hace que t¡ 
sea permanente (a diferencia de la situación del Capí¬ 
tulo 17). En vez de eso, t¡ se compromete con T, y pue¬ 
de que todavía aborte (o exija compensación; véase el 
Apartado 24.5.4) si T aborta. La ejecución de T no debe 
violar el orden parcial P. Es decir, si un trazo l ¡ —» t ¡ apa¬ 
rece en el grafo de precedencia, t j —> t¡ no debe estar en 
el cierre transitivo de P. 

El anidamiento puede tener varios niveles de profun¬ 
didad, representando la subdivisión de una transacción en 
subtareas, subsubtareas, etcétera. En el nivel inferior de 
anidamiento se tienen las operaciones estándar de bases 
de datos leer y escribir que se han utilizado anteriormente. 

Si se permite a una subtransacción de T liberar los 
bloqueos al completarse, T se denomina transacción 
multinivel. Cuando una transacción multinivel repre¬ 
senta una actividad de larga duración, a veces se deno¬ 
mina saga. De manera alternativa, si los bloqueos man¬ 
tenidos por la subtransacción t¡ de T se asignan de 
manera automática a T al concluir t¡, T se denomina tran¬ 
sacción anidada. 

Aunque el principal valor práctico de las transac¬ 
ciones multinivel surja en las transacciones complejas 
de larga duración, se utilizará el sencillo ejemplo de la 
Figura 24.5 para mostrar el modo en que el anidamien¬ 
to puede crear operaciones de nivel superior que pue¬ 
den mejorar la concurrencia. Se reescribe la transacción 
7j, mediante las subtransacciones 7j, y 7j 2 , que llevan 
a cabo operaciones de suma o de resta: 

• T j consiste en 

— T l v que resta 50 de A 
— T ia , que suma 50 a B 

De manera parecida, se reescribe la transacción T 2 , 
mediante las subtransacciones T 2 ' 1 y T 22 , que también 
llevan a cabo operaciones de suma o de resta: 

• T 2 consiste en 

— T 2 V que resta 10 de B 
— T 22 , que suma 10 a A 

No se especifica ninguna ordenación para T lv 7) 2 , T 2 , 
y T 2 2 . Cualquier ejecución de estas subtransacciones 
generará un resultado correcto. La planificación de la 
Figura 24.5 corresponde a la planificación <7j ,, 1 \,, 
T T > 

1 1,2’ 2X’ 


24.5.4. Transacciones compensadoras 

Para reducir la frecuencia de las esperas de larga dura¬ 
ción se dispone que las actualizaciones no comprome¬ 
tidas se muestren a otras transacciones que se ejecuten 
de manera concurrente. En realidad, las transacciones 
multinivel pueden permitir esta exposición. No obstan¬ 
te, la exposición de datos no comprometidos crea la 
posibilidad de retrocesos en cascada. El concepto de 
transacciones compensadoras ayuda a tratar este pro¬ 
blema. 

Divídase la transacción T en varias subtransacciones 
t v t 2 ,.. t n . Una vez comprometida la subtransacción t¡, 
libera sus bloqueos. Ahora, si hay que abortar la tran¬ 
sacción del nivel externo T, hay que deshacer el efecto 
de sus subtransacciones. Supóngase que las subtran¬ 
sacciones t v ..., t k se han comprometido y que t k+l se 
estaba ejecutando cuando se tomó la decisión de abor¬ 
tar. Se pueden deshacer los efectos de t k+l abortando esa 
subtransacción. Sin embargo, no es posible abortar las 
subtransacciones t v .... t k , puesto que ya se han com¬ 
prometido. 

En lugar de eso, se ejecuta una nueva subtransacción 
tc¡ , denominada transacción compensadora, para des¬ 
hacer el efecto de cada subtransacción t¡. Es necesario 
que cada subtransacción t¡ tenga su transacción com¬ 
pensadora tc¡. Las transacciones compensadoras deben 
ejecutarse en el orden inverso tc k , tc v A continua¬ 
ción se ofrecen varios ejemplos de compensaciones: 

• Considérese la planificación de la Figura 24.5, que 
se ha demostrado que es correcta, aunque no 
secuenciable en cuanto a conflictos. Cada sub¬ 
transacción libera sus bloqueos una vez se com¬ 
pleta. Supóngase que T 2 falla justo antes de su ter¬ 
minación, una vez que T 22 ha liberado sus 
bloqueos. Se ejecuta una transacción compensa¬ 
dora para T 2 2 que resta 10 de A y una transacción 
compensadora para T 2 , que suma 10 a B. 

• Considérese una inserción en la base de datos por 
la transacción T¡ que, como efecto lateral, provo¬ 
ca que se actualice el índice del árbol B + . La ope¬ 
ración de inserción puede haber modificado varios 
nodos del índice del árbol B + . Otras transacciones 
pueden haber leído estos nodos al tener acceso a 
datos diferentes del registro insertado por T¡. Como 
en el Apartado 17.9, se puede deshacer la inser¬ 
ción eliminando el registro insertado por T¡. El 
resultado es un árbol B + correcto y consistente, 
pero no necesariamente uno con exactamente la 
misma estructura que la que se tenía antes de que 
se iniciara T¡. Por tanto, la eliminación es una 
acción compensadora para la inserción. 

• Considérese una transacción de larga duración 7j 
que represente una reserva de viaje. La transacción 
T tiene tres subtransacciones: T i X , que hace las 
reservas de billetes de avión; T iV que reserva los 
coches de alquiler; y T i3 , que reserva las habita- 
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ciones de hotel. Supóngase que el hotel cancela la 
reserva. En lugar de deshacer todas las T¡, se com¬ 
pensa el fallo de T ¡3 eliminando la reserva de hotel 
antigua y realizando una nueva. 

Si el sistema falla en medio de la ejecución de una 
transacción del nivel externo hay que hacer retroceder 
sus subtransacciones cuando se recupere. Las técnicas 
descritas en el Apartado 17.9 pueden utilizarse con este 
fin. 

La compensación del fallo de una transacción exige 
que se utilice la semántica de la transacción que ha falla¬ 
do. Para determinadas operaciones, como el incremen¬ 
to o la inserción en un árbol B + , la compensación corres¬ 
pondiente se define con facilidad. Para transacciones 
más complejas puede que los planificadores de la apli¬ 
cación tengan que definir la forma correcta de com¬ 
pensación en el momento en que se codifique la tran¬ 
sacción. Para las transacciones interactivas complejas 
puede que sea necesario que el sistema interactúe con 
el usuario para determinar la forma adecuada de com¬ 
pensación. 

24.5.5. Problemas de implementación 

Los conceptos sobre las transacciones estudiados en este 
apartado crean serias dificultades para su implementa¬ 
ción. Aquí se presentan unos cuantos y se estudia el 
modo de abordar esos problemas. 

Las transacciones de larga duración deben sobrevi¬ 
vir a los fallos del sistema. Se puede asegurar que lo 
harán llevando a cabo una operación rehacer con las 
subtransacciones comprometidas, y llevando a cabo una 
operación deshacer o una compensación para cualquier 
subtransacción de corta duración que estuviera activa 
en el momento del fallo. Sin embargo, estas acciones 
sólo resuelven parte del problema. En los sistemas típi¬ 
cos de bases de datos los datos intemos del sistema como 
las tablas de bloqueos y las marcas temporales de las 
transacciones se conservan en almacenamiento volátil. 
Para que se pueda reanudar una transacción de larga 
duración tras un fallo hay que restaurar esos datos. Por 
tanto, es necesario registrar no sólo las modificaciones 
de la base de datos, sino también las modificaciones de 
los datos internos del sistema correspondientes a las 
transacciones de larga duración. 

El registro histórico de las actualizaciones se hace 
más complicado cuando hay en la base de datos ciertos 
tipos de elementos de datos. Un elemento de datos pue¬ 
de ser un diseño CAD, el texto de un documento u otra 


forma de diseño compuesto. Estos elementos de datos 
son de gran tamaño físico. Por tanto, guardar los valo¬ 
res antiguos y nuevos del elemento de datos en un regis¬ 
tro del registro histórico no resulta deseable. 

Hay dos enfoques para reducir la sobrecarga de ase¬ 
gurar la recuperabilidad de elementos de datos de gran 
tamaño: 

• Registro histórico de operaciones. Sólo se guar¬ 
dan en el registro histórico la operación llevada a 
cabo en el elemento de datos y el nombre del ele¬ 
mento de datos. El registro histórico de operacio¬ 
nes también se denomina registro histórico lógi¬ 
co. Para cada operación debe haber una operación 
inversa. Se lleva a cabo la operación deshacer uti¬ 
lizando la operación inversa y la operación reha¬ 
cer utilizando la misma operación. La recupera¬ 
ción mediante el registro histórico de operaciones 
resulta más difícil, ya que rehacer y deshacer no 
son idempotentes. Además, el empleo del registro 
lógico para una operación que actualice varias pági¬ 
nas resulta muy complicado debido al hecho de 
que algunas, pero no todas, las páginas actualiza¬ 
das pueden haberse escrito en el disco, por lo que 
resulta difícil aplicar tanto rehacer como desha¬ 
cer a la operación en la imagen del disco durante 
la recuperación. 

El empleo del registro histórico físico de reha¬ 
cer y registro histórico lógico de deshacer tal y 
como se describe en el Apartado 17.9 proporcio¬ 
na las ventajas de concurrencia del registro histó¬ 
rico lógico y evita los inconvenientes mencio¬ 
nados. 

• Registro histórico y paginación en la sombra. 

El registro se utiliza para las modificaciones de 
elementos de datos de pequeño tamaño, pero los 
elementos de datos de gran tamaño se hacen recu¬ 
perables mediante una técnica de paginación en la 
sombra (véase el Apartado 17.5). Cuando se utili¬ 
za esta técnica sólo hace falta almacenar por dupli¬ 
cado las páginas que se modifican realmente. 

Independientemente de la técnica empleada, las com¬ 
plejidades introducidas por las transacciones de larga 
duración y los elementos de datos de gran tamaño com¬ 
plican el proceso de recuperación. Por tanto, resulta 
deseable permitir que algunos datos no esenciales que¬ 
den exentos del registro, y confiar en las copias de segu¬ 
ridad fuera de línea y en la intervención de las perso¬ 
nas. 
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24.6. GESTIÓN DE TRANSACCIONES EN VARIAS BASES DE DATOS 


Hay que recordar del Apartado 19.8 que un sistema con 
varias bases de datos crea la ilusión de una integración 
lógica de las bases de datos, en un sistema de bases de 
datos heterogéneo en el que los sistemas locales de bases 
de datos pueden emplear diferentes modelos lógicos de 
datos y lenguajes de definición y de manipulación dife¬ 
rentes, y pueden diferenciarse en sus mecanismo de con¬ 
trol de concurrencia y de gestión de las transacciones. 

Los sistemas con varias bases de datos soportan dos 
tipos de transacciones: 

1. Transacciones locales. Estas transacciones las 
ejecuta cada sistema local de base de datos fuera 
del control del sistema con varias bases de datos. 

2. Transacciones globales. Estas transacciones se 
ejecutan bajo el control del sistema con varias 
bases de datos. 

El sistema con varias bases de datos es consciente del 
hecho de que pueden ejecutarse transacciones locales 
en los sitios locales, pero no de las transacciones con¬ 
cretas que se ejecutan, ni de los datos a los que tienen 
acceso. 

Asegurar la autonomía local de cada sistema de bases 
de datos exige que no se realice ningún cambio en su 
software. Por tanto, el sistema de bases de datos de un 
sitio no puede comunicarse directamente con los de otros 
sitios para sincronizar la ejecución de transacciones glo¬ 
bales activas en varios sitios. 

Dado que el sistema con varias bases de datos no tie¬ 
ne ningún control sobre la ejecución de las transaccio¬ 
nes globales, cada sistema local debe utilizar un esque¬ 
ma de control de concurrencia (por ejemplo, el 
compromiso de dos fases o las marcas temporales) para 
asegurarse de que su planificación sea secuenciable. 
Además, en caso de bloqueo, cada sistema local debe 
poder protegerse contra la posibilidad de interbloqueos 
locales. 

La garantía de la secuencialidad local no es suficiente 
para asegurar la secuencialidad global. Como ejemplo, 
considérense dos transacciones globales 7j y 7’,, cada 
una de las cuales tiene acceso y actualiza a dos ele¬ 
mentos de datos, Ay B, ubicados en los sitios Sj y S 2 , 
respectivamente. Supóngase que las planificaciones loca¬ 
les son secuenciables. Sigue siendo posible que haya 
una situación en la que, en el sitio Sj, T 2 siga a /j, mien¬ 
tras que, en S 2 , 7j siga a T 2 , dando como resultado una 
planificación global no secuenciable. En realidad, aun¬ 
que no haya concurrencia entre las transacciones glo¬ 
bales (es decir, cada transacción global sólo se remite 
una vez que la anterior se compromete o aborta), la 
secuencialidad local no resulta suficiente para asegurar 
la secuencialidad global (véase el Ejercicio 24.14). 

En función de la implementación de los sistemas 
locales de bases de datos puede que una transacción glo¬ 


bal no pueda controlar el comportamiento exacto de los 
bloqueos de sus subtransacciones. Por tanto, incluso si 
todos los sistemas locales de bases de datos siguen el 
bloqueo de dos fases, puede que sólo sea posible ase¬ 
gurar que cada transacción local sigue las reglas del pro¬ 
tocolo. Por ejemplo, puede que un sistema local de bases 
de datos comprometa su subtransacción y libere sus blo¬ 
queos mientras que la subtransacción de otro sistema 
local se sigue ejecutando. Si los sistemas locales per¬ 
miten el control del comportamiento de los bloqueos y 
todos los sistemas siguen el bloqueo de dos fases, el sis¬ 
tema con varias bases de datos puede asegurar que las 
transacciones globales se bloqueen en la modalidad de 
dos fases y que los puntos de bloqueo de las transac¬ 
ciones en conflicto definan su orden global de secuen¬ 
cia. Si diferentes sistemas locales siguen diferentes 
mecanismos de control de concurrencia, sin embargo, 
esta forma directa de control global no funciona. 

Hay muchos protocolos para asegurar la consisten¬ 
cia pese a la ejecución concurrente de las transacciones 
globales y locales en los sistemas con varias bases de 
datos. Algunos se basan en imponer las condiciones sufi¬ 
cientes para asegurar la secuencialidad global. Otros 
sólo aseguran una forma de consistencia más débil que 
la secuencialidad, pero la consiguen por medios menos 
restrictivos. Se considerará uno de estos últimos esque¬ 
mas: la secuencialidad de dos niveles. El Apartado 24.5 
describe más enfoques de la consistencia sin secuen¬ 
cialidad; se citan otros enfoques en las notas bibliográ¬ 
ficas. 

Un problema relacionado en los sistemas de bases 
de datos es el del compromiso atómico global. Si todos 
los sistemas locales siguen el protocolo de compromi¬ 
so de dos fases, puede utilizarse este protocolo para con¬ 
seguir la atomicidad global. No obstante, puede que los 
sistemas locales no diseñados para ser parte de un sis¬ 
tema distribuido no puedan participar en este protoco¬ 
lo. Aunque un sistema local pueda soportar el compro¬ 
miso de dos fases, la organización propietaria del sistema 
puede que no desee permitir las esperas en los casos en 
los que se producen bloqueos. En esos casos, pueden 
alcanzarse compromisos que permitan la falta de ato¬ 
micidad en determinadas modalidades de fallo. En la 
literatura proporcionada hay un tratamiento más exten¬ 
so de estos asuntos (véanse las notas bibliográficas). 

24.6.1. Secuencialidad de dos niveles 

La secuencialidad de dos niveles (S2N) asegura la 
secuencialidad en dos niveles del sistema: 

• Cada sistema local de bases de datos asegura la 
secuencialidad local entre sus transacciones loca¬ 
les, incluidas las que forman parte de las transac¬ 
ciones globales. 
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• El sistema con varias bases de datos asegura sólo 
la secuencialidad entre las transacciones globales, 
ignorando las ordenaciones inducidas por las tran¬ 
sacciones locales. 

Resulta sencillo hacer que se cumpla cada uno de estos 
niveles de secuencialidad. Los sistemas locales ya ofre¬ 
cen garantías de secuencialidad; por tanto, el primer requi¬ 
sito es sencillo de lograr. El segundo requisito sólo se apli¬ 
ca a una proyección de la planificación global en la que 
las transacciones locales no aparecen. Por tanto, el siste¬ 
ma con varias bases de datos puede asegurar el segundo 
requisito utilizando técnicas estándar de control de con¬ 
currencia (no importa la elección concreta de la técnica). 

Los dos requisitos de S2N no resultan suficientes 
para asegurar la secuencialidad global. Sin embargo, 
con el enfoque S2N, se adopta un requisito más débil 
que la secuencialidad, denominado corrección fuerte: 

1. La conservación de la consistencia tal y como 
especifica un conjunto de restricciones de con¬ 
sistencia. 

2. La garantía de que el conjunto de elementos de 
datos leído por cada transacción es consistente. 

Puede probarse que determinadas restricciones al com¬ 
portamiento de las transacciones, combinadas con S2N, 
son suficientes para asegurar la corrección fuerte (aun¬ 
que no necesariamente para asegurar la secuencialidad). 
Se citarán varias de estas restricciones. 

En cada uno de los protocolos se distingue entre los 
datos locales y los datos globales. Los elementos loca¬ 
les de datos pertenecen a un sitio concreto y se hallan 
bajo el control exclusivo de ese sitio. Obsérvese que no 
puede haber restricciones de consistencia entre los ele¬ 
mentos locales de datos de sitios distintos. Los elementos 
globales de datos pertenecen al sistema con varias bases 
de datos y, aunque puede que se almacenen en un sitio 
local, se hallan bajo el control del sistema con varias 
bases de datos. 

El protocolo globales-lectura permite que las tran¬ 
sacciones globales lean, pero no actualicen, los ele¬ 
mentos locales de datos, mientras que impide el acce¬ 
so a los datos globales por parte de las transacciones 
locales. El protocolo globales-lectura asegura la correc¬ 
ción fuerte si se cumplen todas las reglas siguientes: 

1. Las transacciones locales sólo tienen acceso a los 
elementos locales de datos. 

2. Las transacciones globales pueden tener acceso 
a los elementos globales de datos, y pueden leer 
los elementos locales de datos (aunque no deben 
escribirlos). 

3. No hay restricciones de consistencia entre los ele¬ 
mentos de datos locales y los globales. 

El protocolo locales-lectura concede a las transac¬ 
ciones locales acceso de lectura a los datos globales, 


pero impide el acceso a los datos locales por las tran¬ 
sacciones globales. En este protocolo hay que introdu¬ 
cir el concepto de dependencia del valor. Cada tran¬ 
sacción tiene una dependencia del valor si el valor que 
escribe en el elemento de datos de un sitio depende del 
valor que ha leído para el elemento de datos de otro sitio. 

El protocolo locales-lectura asegura la corrección 
fuerte si se cumplen todas las condiciones siguientes: 

1. Las transacciones locales pueden tener acceso a 
los elementos locales de datos y pueden leer los 
elementos globales de datos almacenados en ese 
sitio (aunque no deban escribir elementos globa¬ 
les de datos). 

2. Las transacciones globales sólo tienen acceso a 
los elementos globales de datos. 

3. Ninguna transacción puede tener dependencia de 
ningún valor. 

El protocolo globales-escritura-lectura/locales- 
lectura es el más generoso en términos de acceso a los 
datos de los protocolos que se han considerado. Permi¬ 
te que las transacciones globales lean y escriban los 
datos locales y que las transacciones locales lean los 
datos globales. Sin embargo, impone tanto la condición 
de dependencia del valor del protocolo locales-lectura 
como la condición del protocolo globales-lectura de que 
no haya restricciones de consistencia entre los datos 
locales y los globales. 

El protocolo globales-escritura-lectura/locales-lec- 
tura asegura la corrección fuerte si se cumplen todas las 
condiciones siguientes: 

1. Las transacciones locales pueden tener acceso a 
los elementos locales de datos y pueden leer los 
elementos globales de datos almacenados en ese 
sitio (aunque no deben escribir los elementos glo¬ 
bales de datos). 

2. Las transacciones globales pueden tener acceso 
a los elementos globales de datos y a los ele¬ 
mentos locales de datos (es decir, pueden leer y 
escribir todos los datos). 

3. No hay restricciones de consistencia entre los ele¬ 
mentos locales de datos y los globales. 

4. Ninguna transacción puede tener dependencia de 
ningún valor. 

24.6.2. Aseguramiento de la secuencialidad 
global 

Los primeros sistemas con varias bases de datos res¬ 
tringían las transacciones globales a ser sólo de lectura. 
Así evitaban la posibilidad de que las transacciones glo¬ 
bales introdujeran inconsistencia en los datos, pero no 
eran lo bastante restrictivas como para asegurar la secuen- 
cialidad global. Resulta posible realmente obtener pla¬ 
nificaciones globales de este tipo y desarrollar un esque- 
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ma para asegurar la secuencialidad global, y se pide al 
lector que haga las dos cosas en el Ejercicio 24.15. 

Hay varios esquemas generales para asegurar la 
secuencialidad global en entornos en los que se pueden 
ejecutar actualizaciones y transacciones sólo de lectu¬ 
ra. Varios de estos esquemas se basan en la idea del bille¬ 
te. Se crea un elemento de datos especial denominado 
billete en cada sistema local de bases de datos. Cada 
transacción global que tenga acceso a los datos de un 
sitio debe escribir en el billete de ese sitio. Este requi¬ 
sito asegura que las transacciones globales entren en 
conflicto directamente en cada sitio que visiten. Ade¬ 
más, el gestor de las transacciones globales puede con¬ 
trolar el orden en el que se secuencian las transaccio¬ 
nes globales controlando el orden en el que tienen acceso 
a los billetes. Las referencias a estos esquemas apare¬ 
cen en las notas bibliográficas. 

Si se desea asegurar la secuencialidad global en entor¬ 
nos en los que no se generan en cada sitio conflictos 


locales directos, hay que realizar algunas suposiciones 
sobre las planificaciones autorizadas por el sistema local 
de bases de datos. Por ejemplo, si las planificaciones 
locales son tales que el orden de compromiso y el de 
secuenciación son siempre idénticos, se puede asegu¬ 
rar la secuencialidad controlando únicamente el orden 
en que se comprometen las transacciones. 

El problema de los esquemas que aseguran la secuen- 
cialidad global es que pueden restringir la concurrencia 
de manera inadecuada. Resultan especialmente pro¬ 
pensos a hacerlo porque la mayor parte de las transac¬ 
ciones remiten al sistema de bases de datos subyacen¬ 
te las sentencias SQL, en lugar de remitir cada uno de 
los pasos de lectura, escritura, compromiso y abor¬ 
to. Aunque sigue siendo posible asegurar la secuencia¬ 
lidad global con esta suposición, el nivel de concurren¬ 
cia puede ser tal que otros esquemas, como la técnica 
de secuencialidad de dos niveles estudiada en el Apar¬ 
tado 24.6.1, resulten alternativas atractivas. 


24.7. RESUMEN 


• Los flujos de trabajo son actividades que implican la 
ejecución coordinada de varias tareas llevadas a cabo 
por diferentes entidades de proceso. No sólo existen 
en las aplicaciones informáticas, sino también en casi 
todas las actividades de una organización. Con el auge 
de las redes y la existencia de numerosos sistemas 
autónomos de bases de datos, los flujos de trabajo 
ofrecen una manera adecuada de llevar a cabo las ta¬ 
reas que implican a varios sistemas. 

• Aunque los requisitos transaccionales ACID habi¬ 
tuales resultan demasiado estrictos o no pueden imple- 
mentarse para estas aplicaciones de flujo de trabajo, 
los flujos de trabajo deben satisfacer un conjunto limi¬ 
tado de propiedades transaccionales que garantiza que 
no se dejen los procesos en estados inconsistentes. 

• Los monitores de procesamiento de transacciones se 
desarrollaron inicialmente como servidores con varias 
hebras que podían atender a un gran número de termi¬ 
nales desde un único proceso. Desde entonces han evo¬ 
lucionado y hoy en día ofrecen la infraestructura para 
la creación y gestión de sistemas complejos de proce¬ 
samiento de transacciones que tienen gran número de 
clientes y varios servidores. Proporcionan servicios 
como colas duraderas de las solicitudes de los clientes 
y de las respuestas de los servidores, el encaminamiento 
de los mensajes de los clientes a los servidores, la men¬ 
sajería persistente, el equilibrio de carga y la coordi¬ 
nación del compromiso de dos fases cuando las tran¬ 
sacciones tienen acceso a varios servidores. 

• Las memorias principales de gran tamaño se aprove¬ 
chan en determinados sistemas para conseguir una 
gran productividad del sistema. En esos sistemas el 


registro lústórico constituye un cuello de botella. Bajo 
el concepto de compromiso en grupo se puede redu¬ 
cir el número de salidas hacia el almacenamiento esta¬ 
ble, lo que libera este cuello de botella. 

• La gestión eficiente de las transacciones interactivas 
de larga duración resulta más compleja debido a las 
esperas de larga duración y a la posibilidad de los 
abortos. Dado que las técnicas de control de concu¬ 
rrencia utilizadas en el Capítulo 16 emplean las espe¬ 
ras, los abortos o las dos cosas, hay que considerar 
técnicas alternativas. Estas técnicas deben asegurar 
la corrección sin exigir la secuencialidad. 

• Las transacciones de larga duración se representan 
como transacciones atómicas con operaciones ató¬ 
micas de la base de datos anidadas en el nivel infe¬ 
rior. Si una transacción falla, sólo se abortan las tran¬ 
sacciones activas de corta duración. Las transacciones 
activas de larga duración se reanudan una vez que se 
han recuperado todas las transacciones de corta dura¬ 
ción. Se necesita una transacción compensadora para 
deshacer las actualizaciones de las transacciones ani¬ 
dadas que se hayan comprometido, si falla la tran¬ 
sacción del nivel exterior. 

• En los sistemas con restricciones de tiempo real la 
corrección de la ejecución no sólo implica la consis¬ 
tencia de la base de datos, sino también el cumplimiento 
de las tiempos límite. La amplia variabilidad de los 
tiempos de ejecución de las operaciones de lectura y de 
escritura complica el problema de la gestión de las tran¬ 
sacciones en sistemas con restricciones temporales. 

• Los sistemas con varias bases de datos proporcionan 
un entorno en el que las nuevas aplicaciones de bases 
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de datos pueden tener acceso a los datos desde gran 
variedad de bases de datos existentes previamente ubi¬ 
cadas en varios entornos heterogéneos de hardware y 
de software. 

• Los sistemas locales de bases de datos pueden em¬ 
plear diferentes modelos lógicos y lenguajes diferen¬ 


tes de definición y de manipulación de datos, y pue¬ 
de que se diferencien en sus mecanismos de control 
de concurrencia y de gestión de las transacciones. Los 
sistemas con varias bases de datos crean la ilusión de 
la integración lógica de las bases de datos sin exigir 
su integración física. 


TÉRMINOS DE REPASO 


• Arquitecturas de los monitores TP 

- Proceso por cliente 

- Servidor único 

- Varios servidores, un encaminador 

- Varios servidores, varios encaminadores 

• Arquitecturas de los sistemas gestores del flujo de tra¬ 
bajo 

- Centralizadas 

- Completamente distribuidas 

- Parcialmente distribuidas 

• Aseguramiento de la secuencialidad global 

• Atomicidad ante fallos del flujo de trabajo 

• Autonomía 

• Bases de datos en memoria principal 

• Bases de datos de tiempo real 

• Billete 

• Cambio de contexto 

• Compromiso en grupo 

• Coordinación de aplicaciones 

- Gestor de recursos 

- Llamada a procedimiento remoto (Remóte Proce- 
dure Cali, RPC) 

• Corrección fuerte 

• Datos globales 

• Datos locales 

• Ejecuciones no secuenciables 

• Estado del flujo de trabajo 

- Estados de ejecución 

- Valores de salida 

- Variables externas 

• Estados de terminación del flujo de trabajo 

- Abortado 

- Aceptable 

- Comprometido 


- No aceptable 

• Exposición de datos no comprometidos 

• Flujos de trabajo transaccionales 

- Ejecución del flujo de trabajo 

- Entidad de procesamiento 

- Especificación del flujo de trabajo 

- Tarea 

• Gestor de la cola 

• Monitor TP 

• Multitarea 

• Protocolos 

- De dependencia del valor 

- Globales-lectura 

- Globales-escritura-lectura/locales-lectura 

- Locales-lectura 

• Recuperación del flujo de trabajo 

• Registro histórico lógico 

• Saga 

• Secuencialidad de dos niveles (S2N) 

• Servidor con varias hebras 

• Sistema gestor de flujos de trabajo 

• Sistemas de tiempo real 

• Subtareas 

• Sistemas con varias bases de datos 

• Tiempos límite 

- Tiempo límite estricto 

- Tiempo límite firme 

- Tiempo límite flexible 

• Transacciones anidadas 

• Transacciones compensadoras 

• Transacciones globales 

• Transacciones de larga duración 

• Transacciones locales 

• Transacciones multinivel 
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EJERCICIOS 


24.1. Expliqúese el modo en que los monitores TP admi¬ 
nistran los recursos de la memoria y del procesador 
de manera más efectiva que los sistemas operativos 
habituales. 

24.2. Compárense las características de los monitores TP 
con las proporcionadas por los servidores web que 
soportan servlets (estos servidores se han denomina¬ 
do TP-lite). 

24.3. Considérese el proceso de admisión de nuevos alum¬ 
nos en la universidad (o de nuevos empleados en la 
organización). 

a. Dese una imagen de alto nivel del flujo de trabajo 
comenzando por el procedimiento de matrícula de 
los estudiantes. 

b. Indíquense los estados de terminación aceptables 
y los pasos que implican intervención de personas. 

c. Indíquense los posibles errores (incluido el venci¬ 
miento del tiempo límite) y el modo en que se tra¬ 
tan. 

d. Estúdiese la cantidad de flujo de trabajo que se ha 
automatizado en la universidad. 

24.4. Al igual que los sistemas de bases de datos, los siste¬ 
mas de flujo de trabajo también necesitan la gestión de 
la concurrencia y de la recuperación. Indíquense tres 
motivos por los que no se puede aplicar simplemente 
un sistema relacional de bases de datos empleando blo¬ 
queo de dos fases, registro histórico de operaciones físi¬ 
cas de deshacer y compromiso de dos fases. 

24.5. Si toda la base de datos cabe en la memoria principal, 
indíquese si sigue haciendo falta un sistema de bases 
de datos para administrar los datos. Expliqúese la res¬ 
puesta. 

24.6. Considérese un sistema de bases de datos en memo¬ 
ria principal que se recupera de un fallo del sistema. 
Expliqúense las ventajas relativas de 

• Volver a cargar toda la base de datos en memoria 
principal antes de reanudar el procesamiento de las 
transacciones. 

• Cargar los datos a medida que los soliciten las tran¬ 
sacciones. 

24.7. En la técnica de compromiso en grupo indicar el 
número de transacciones que deben formar parte de 
un grupo. Expliqúese la respuesta. 

24.8. Indíquese si un sistema de transacciones de alto ren¬ 
dimiento es necesariamente un sistema de tiempo real. 
Expliqúese el motivo. 


24.9. En un sistema de bases de datos que utilice el regis¬ 
tro histórico de escritura adelantada indíquese el núme¬ 
ro de accesos a disco necesarios para leer un elemen¬ 
to de datos en el peor caso posible. Expliqúese el 
motivo por el que esto supone un problema para los 
diseñadores de sistemas de bases de datos de tiempo 
real. 

24.10. Expliqúese el motivo por el que puede que no resul¬ 
te práctico exigir la secuencialidad para las transac¬ 
ciones de larga duración. 

24.11. Considérese un proceso con varias hebras que entre¬ 
ga mensajes desde una cola duradera de mensajes per¬ 
sistentes. Pueden ejecutarse de manera concurrente 
diferentes hebras, que intentan entregar mensajes dife¬ 
rentes. En caso de fallo en la entrega, el mensaje debe 
restaurarse en la cola. Modélense las acciones que lle¬ 
va a cabo cada hebra como una transacción multini- 
vel, de manera que no haga falta mantener los blo¬ 
queos en la cola hasta que se entregue cada mensaje. 

24.12. Discútanse las modificaciones que hay que hacer en 
cada uno de los esquemas de recuperación tratados en 
el Capítulo 17 si se permiten las transacciones anida¬ 
das. Expliqúense también las diferencias que se pro¬ 
ducen si se permiten las transacciones multinivel. 

24.13. Indíquese la finalidad de las transacciones compen¬ 
sadoras. Preséntense dos ejemplos de su empleo. 

24.14. Considérese un sistema con varias bases de datos en 
el que se garantice que, como máximo, está activa una 
transacción global en un momento dado y que cada 
sistema local asegura la secuencialidad local. 

a. Sugiéranse maneras de que el sistema con varias 
bases de datos pueda asegurar que haya como máxi¬ 
mo una transacción global activa en cualquier 
momento dado. 

b. Demuéstrese mediante un ejemplo que resulta posi¬ 
ble que se produzca una planificación global no 
secuenciable pese a estas suposiciones. 

24.15. Considérese un sistema con varias bases de datos en 
el que cada sitio local asegura la secuencialidad local 
y todas las transacciones globales son sólo de lectura. 

a. Demuéstrese mediante un ejemplo que pueden pro¬ 
ducirse ejecuciones no secuenciables en este siste¬ 
ma. 

b. Muéstrese la manera en que se podría utilizar un 
esquema de billete para asegurar la secuencialidad 
global. 
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NOTAS BIBLIOGRÁFICAS 


Gray y Edwards [1995] proporcionan una introducción 
a las arquitecturas de los monitores TP; Gray y Reuter 
[1993] ofrecen una descripción detallada (y excelente) 
con nivel de libro de texto de los sistemas de procesa¬ 
miento de transacciones, incluidos capítulos sobre los 
monitores TP. La descripción que se ha dado de los 
monitores TP se basa en estas dos fuentes. X/Open 
[1991] define la interfaz X/Open XA. El procesamien¬ 
to de las transacciones en Tuxedo se describe en Huff¬ 
man [1993]. Wipfler [1987] es uno de los textos sobre 
el desarrollo de aplicaciones mediante CICS. 

Fischer [2001] es un manual sobre los sistemas de 
flujo de trabajo. Un modelo de referencia para los flu¬ 
jos de trabajo, propuesto por la Coalición para la ges¬ 
tión de flujos de trabajo (Workflow Management Coa- 
lition), se presenta en Hollinsworth [1994]. El sitio web 
de la coalición es www.wfmc.org. La descripción de 
flujos de trabajo que se ha dado sigue el modelo de 
Rusinkiewicz y Sheth [1995]. 

Reuter [1989] presenta ConTracts, un método para 
agrupar las transacciones en actividades con varias tran¬ 
sacciones. Algunos problemas relativos a los flujos de 
trabajo se abordan en el trabajo sobre las actividades de 
larga duración descritas por Dayal et al. [1990] y Dayal 
et al. [1991]. Los autores proponen las reglas de even¬ 
to-condición-acción como una técnica para especificar 
los flujos de trabajo. Jin et al. [1993] describen los pro¬ 
blemas de los flujos de trabajo en las aplicaciones de 
telecomunicaciones. 

García-Molina y Salem [1992] ofrecen una intro¬ 
ducción a las bases de datos en memoria principal. Jaga- 
dish et al. [1993] describen un algoritmo de recupera¬ 
ción diseñado para las bases de datos en memoria 
principal. En Jagadish et al. [1994] se describe un ges¬ 
tor de almacenamiento para las bases de datos en memo¬ 
ria principal. 

El procesamiento de transacciones en las bases de 
datos de tiempo real se estudia en Abbott y García-Moli¬ 
na [1999] y en Dayal et al. [1990]. Barclay et al. [1982] 
describen un sistema de bases de datos de tiempo real 
empleado en un sistema de conmutación de telecomu¬ 
nicaciones. Los problemas de la complejidad y de la 
corrección en las bases de datos de tiempo real se abor¬ 
dan en Korth et al. [1990b] y en Soparkar et al. [1995]. 
El control de concurrencia y las planificaciones en las 
bases de datos de tiempo real se estudian en Haritsa et 
al. [1990], en Hong et al. [1993] y en Pang et al. [1995]. 


Ozsoyoglu y Snodgrass [1995] es una reseña de la inves¬ 
tigación en las bases de datos de tiempo real y en las 
bases de datos temporales. 

Las transacciones anidadas y las transacciones mul- 
tinivel se presentan en Lynch [1983], Moss [1982], Moss 
[1985], Lynch y Merritt [1986], Fekete et al. [1990b], 
Fekete et al. [1990a], Korth y Speegle [1994] y Pu et 
al. [1988]. Los aspectos teóricos de las transacciones 
multinivel se presentan en Lynch et al. [1988] y en Weihl 
y Liskov [1990]. Se han definido varios modelos de tran¬ 
sacciones ampliadas, incluidos Sagas (García-Molina y 
Salem [1987]), ACTA (Chrysanthis y Ramamritham 
[1994]), el modelo Con-Tract (Wachter y Reuter [1992]), 
ARIES (Mohán et al. [1992] y Rothermel y Mohán 
[1989]) y el modelo NT/PV (Korth y Speegle [1994]). 

El fraccionamiento de las transacciones para conse¬ 
guir un rendimiento mayor se aborda en Shasha et al. 
[1995]. Beeri et al. [1989] presentan un modelo para la 
concurrencia en los sistemas de transacciones anidadas. 
El relajamiento de la secuencialidad se estudia en Gar¬ 
cía-Molina [1983] y en Sha et al. [1988]. La recupera¬ 
ción en los sistemas de transacciones anidadas se estu¬ 
dia en Moss [1987], Haerder y Rothermel [1987] y 
Rothermel y Mohán [1989]. La gestión de las transac¬ 
ciones multinivel se estudia en Weikum [1991]. 

Gray [1981], Skarra y Zdonik [1989], Korth y 
Speegle [1988] y Korth y Speegle [1990] estudian las 
transacciones de larga duración. El procesamiento de 
las transacciones para las transacciones de larga dura¬ 
ción se considera en Weikum y Schek [1984], Haerder 
y Rothermel [1987], Weikum et al. [1990] y Korth et 
al. [1990a]. Salem et al. [1994] presentan una extensión 
del bloqueo de dos fases para las transacciones de lar¬ 
ga duración al permitir la liberación precoz de los blo¬ 
queos en ciertas circunstancias. El procesamiento de las 
transacciones en las aplicaciones de diseño y de inge¬ 
niería del software se estudia en Korth et al. [1988], Kai¬ 
ser [1990] y Weikum [1991]. 

El procesamiento de las transacciones en los siste¬ 
mas con varias bases de datos se estudia en Breitbart et 
al. [1990], Breitbart et al. [1991], Breitbart et al. [1992], 
Soparkar et al. [1991], Mehrotra et al. [1992b] y Meh- 
rotra et al. [1992a]. El esquema del billete se presenta 
en Georgakopoulos et al. [1994]. S2N se introduce en 
Mehrotra et al. [1991]. Un enfoque anterior, denomi¬ 
nado cuasi-secuencialidad, se presenta en Du y Elma- 
garmid [1989], 
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C uando se fundó Oracle en 1977 como Software Development Laboratories por Larry 
Ellison, Bob Miner y Ed Oates no había productos de bases de datos relaciónales comer¬ 
ciales. La compañía, cuyo nombre cambió posteriormente a Oracle, se estableció para 
construir un sistema de gestión de bases de datos como producto comercial y fue la primera en 
lanzarlo al mercado. Desde entonces Oracle ha mantenido una posición líder en el mercado de 
las bases de datos relaciónales, pero con el paso de los años su producto y servicios ofrecidos 
han crecido más allá del servicio de este campo. Aparte de las herramientas directamente rela¬ 
cionadas con el desarrollo y gestión de bases de datos Oracle vende herramientas de inteligen¬ 
cia de negocio, incluyendo sistemas de gestión de bases de datos multidimensionales y un ser¬ 
vidor de aplicaciones con una integración cercana al servidor de la base de datos. 

Aparte de los servidores y herramientas relacionados con las bases de datos, la compañía 
ofrece software para la planificación empresarial de recursos y gestión de relaciones con el 
cliente, incluyendo áreas como finanzas, recursos humanos, manufactura, márketing, ventas y 
gestión de cadenas de suministro. La unidad Business OnLine de Oracle ofrece servicios en 
estas áreas como un proveedor de servicios de aplicación. 

Este capítulo cubre un subconjunto de características, opciones y funcionalidad de los pro¬ 
ductos Oracle. Continuamente se desarrollan nuevas versiones de los productos, por lo que las 
descripciones de los productos están sujetas a cambios. Este conjunto de características des¬ 
crito aquí está basado en la primera versión de Oracle9i. Antes de abordar a fondo cada uno de 
los temas se resumirá la motivación de cada uno de estos tipos de datos y algunos problemas 
importantes del trabajo con ellos. 


25.1. HERRAMIENTAS PARA EL DISEÑO DE BASES DE DATOS Y LA CONSULTA 


Oracle proporciona una serie de herramientas para el 
diseño, consulta, generación de informes y análisis de 
datos para bases de datos, incluyendo OLAP. 

25.1.1. Herramientas para el diseño de bases 
de datos 

La mayor parte de las herramientas de diseño de Ora¬ 
cle están incluidas en Oracle Internet Development Sui¬ 
te. Se trata de una familia de herramientas para los dis¬ 
tintos aspectos de desarrollo de aplicaciones, incluyendo 
herramientas para el desarrollo de formularios, mode¬ 
lado de datos, informes y consultas. La familia de pro¬ 
ductos soporta el estándar UML (véase el Apartado 2.10) 
para el modelado. Proporciona modelado de clases para 
generar código para componentes de negocio para un 
entorno Java así como modelado de actividades para el 
modelado del flujo de control de propósito general. La 
familia también soporta XML para el intercambio de 
datos con otras herramientas UML. 

La principal herramienta de diseño de bases de datos 
en la familia es Oracle Designer, que traduce la lógica 
de negocio y el flujo de datos en definiciones de esque¬ 
mas y guiones procedimentales para la lógica de las apli¬ 


caciones. Soporta varias técnicas de modelado tales 
como diagramas E-R, ingeniería de información y aná¬ 
lisis y diseño de objetos. Oracle Designer almacena el 
diseño en Oracle Repository, que sirve como un único 
punto de metadatos para la aplicación. 

Los metadatos se pueden entonces utilizar para gene¬ 
rar formularios e informes. Oracle Repository propor¬ 
ciona gestión de la configuración para objetos de bases 
de datos, formularios, clases Java, archivos XML y otros 
tipos de archivos. 

La familia también contiene herramientas de de¬ 
sarrollo de aplicaciones para generar formularios, infor¬ 
mes, y herramientas para distintos aspectos de desa¬ 
rrollo basado en Java y XML. El componente de 
inteligencia de negocio proporciona JavaBeans para fun¬ 
cionalidad analítica tal como visualización de datos, 
consultas y cálculos analíticos. 

Oracle también posee una herramienta de desarrollo 
de aplicaciones para el almacén de datos. Oracle Ware- 
house Builder. Warehouse Builder es una herramienta 
para el diseño e implantación de todos los aspectos de 
un almacén de datos, incluyendo el diseño del esque¬ 
ma, asignaciones de datos y transformaciones, proce¬ 
samiento de carga de datos y gestión de metadatos. Ora- 


611 






FUNDAMENTOS DE BASES DE DATOS 


ele Warehouse Builder soporta los esquemas 3FN y en 
estrella y puede también importar diseños desde Oracle 
Designen 

25.1.2. Herramientas de consulta 

Oracle proporciona herramientas de consulta, genera¬ 
ción de informes y análisis de datos ad hoc, incluyen¬ 
do OLAP. 

Oracle Discoverer es una herramienta basada en Web 
para realizar consultas, informes, análisis y publicación 
Web ad hoc para usuarios finales y analistas de datos. 
Permite a los usuarios abstraer y concretar conjuntos de 
resultados de datos pivote y almacenar cálculos como 
informes que se pueden publicar en una serie de forma¬ 
tos tales como hojas de datos o HTML. Discoverer con¬ 
tiene asistentes que ayudan a los usuarios finales a visua¬ 
lizar los datos como gráficos. Oracle9i soporta un amplio 
conjunto de funciones analíticas tales como la agrega¬ 
ción de clasificación y traslado en SQL. La interfaz de 
consulta de Discoverer puede generar SQL del que se 
puede aprovechar su funcionalidad y puede proporcio¬ 
nar a los usuarios finales una rica funcionalidad analíti¬ 
ca. Puesto que el procesamiento tiene lugar en el sistema 
de gestión de la base de datos relacional, Discoverer no 
requiere un complejo motor de cálculo en el lado del 
cliente, y hay una versión de Discoverer con exploración. 

Oracle Express Server es un servidor de bases de 
datos multidimensionales. Soporta una amplia variedad 
de consultas analíticas, así como previsiones, modela¬ 
do y gestión del escenario. Puede utilizar un sistema de 
gestión de bases de datos relaciónales como un dorsal 
para almacenamiento o utilizar su propio almacena¬ 
miento multidimensional de los datos. 

Con la introducción de los servicios OLAP en Ora- 
cle9i, Oracle está evitando un motor de almacenamien¬ 
to separado y trasladando la mayor parte de los cálculos 
a SQL. El resultado es un modelo donde todos los datos 
residen en el sistema de gestión de la base de datos rela¬ 
cional, y los cálculos que no se pueden realizar en SQL 
se realizan en un motor de cálculo que se ejecuta en el 
servidor de la base de datos. El modelo también pro¬ 
porciona una interfaz para la programación de aplica¬ 


ciones Java OLAP. Hay muchas razones para evitar un 
motor de almacenamiento multidimensional separado: 

• Un motor relacional puede dimensionarse a con¬ 
juntos de datos mucho mayores. 

• Se puede utilizar un modelo de seguridad común 
para las aplicaciones analíticas y el almacén de 
datos. 

• El modelado multidimensional se puede integrar 
con el modelado del almacén de datos. 

• El sistema de gestión de la base de datos relacio¬ 
nal tiene un conjunto mayor de características y 
funcionalidad en muchas áreas tales como alta dis¬ 
ponibilidad, copia de seguridad y recuperación y 
soporte para herramientas de terceros. 

• No hay necesidad de formar administradores de 
bases de datos para dos motores de bases de datos. 

El principal reto al evitar un motor de bases de datos 
multidimensional separado es proporcionar el mismo 
rendimiento. Un sistema de gestión de bases de datos 
mutidimensional que materializa todo o grandes partes 
de un cubo de datos puede ofrecer tiempos de respues¬ 
ta muy cortos para muchos cálculos. Oracle ha enfoca¬ 
do este problema de dos formas. 

• Oracle ha agregado soporte SQL para un amplio 
rango de funciones analíticas, incluyendo cubos, 
abstracciones, conjuntos de agrupación, clasifica¬ 
ciones ( ranks ), agregación de traslado, funciones 
led y lag, cajones de histograma, regresión lineal 
y desviación estándar, junto con la capacidad de 
optimizar la ejecución de dichas funciones en el 
motor de la base de datos. 

• Oracle ha extendido las vistas materializadas para 
permitir funciones analíticas, en particular los con¬ 
juntos de agrupación. La capacidad de materiali¬ 
zar partes o todo el cubo es primordial para el ren¬ 
dimiento de un sistema de gestión de bases de datos 
multidimensionales y las vistas materializadas pro¬ 
porcionan al sistema de gestión de bases de datos 
relaciónales la capacidad de realizar lo mismo. 


25.2. VARIACIONES Y EXTENSIONES DE SQL 


Oracle9i soporta todas las características principales 
de SQL: 1999, con algunas pequeñas excepciones tales 
como distintos tipos de datos. Además, Oracle sopor¬ 
ta un gran número de otras constructoras del lengua¬ 
je, algunas de las cuales casan con SQL: 1999, mien¬ 
tras que otras son específicas de Oracle en sintaxis o 
funcionalidad. Por ejemplo Oracle soporta las opera¬ 
ciones OLAP descritas en el Apartado 22.2, inclu¬ 
yendo clasificación, agregación de traslado, cubos y 
abstracción. 


Algunos ejemplos de las extensiones SQL de Oracle 
son: 

• connect by, que es una forma de recorrido de árbo¬ 
les que permite cálculos al estilo del cierre transi¬ 
tivo en una única instrucción SQL. Es una sinta¬ 
xis específica de Oracle para una característica que 
Oracle tenía desde los años 80. 

• Upsert e inserciones en varias tablas. La opera¬ 
ción upsert combina una actualización y una inser- 
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ción y es útil para combinar datos nuevos con anti¬ 
guos en aplicaciones de almacén de datos. Si una 
nueva fila tiene el mismo valor de clave que una 
fila antigua se actualiza la fila antigua (por ejem¬ 
plo agregando los valores desde la nueva fila), en 
otro caso se inserta la nueva fila en la tabla. Las 
inserciones en varias tablas permiten actualizar 
varias tablas basándose en una única exploración 
de los nuevos datos. 

• cláusula with, que se describe en el Apartado 4.8.2. 

25.2.1. Características relaciónales orientadas 
a objetos 

Oracle tiene soporte extensivo para constmctores rela¬ 
ciónales orientados a objetos, incluyendo: 

• Tipos de objetos. Se soporta un único modelo de 
herencia para las jerarquías de tipos. 

• Tipos de colecciones. Oracle soporta varrays, que 
son arrays de longitud variable, y tablas anidadas. 

• Tablas de objetos. Se utilizan para almacenar obje¬ 
tos mientras se proporciona una vista relacional de 
los atributos de los objetos. 

• Funciones de tablas. Son funciones que produ¬ 
cen conjuntos de filas como salida y se pueden uti¬ 
lizar en la cláusula from de una consulta. Las fun¬ 
ciones de tablas se pueden anidar en Oracle. Si una 
función de tablas se utiliza para expresar algún for¬ 
mulario de transformación de datos, el anidamiento 
de varias funciones permite que se expresen varias 
transformaciones en una única instrucción. 

• Vistas de objetos. Proporcionan una vista de tablas 
de objetos virtuales de datos almacenados en una 
tabla relacional normal. Permite acceder o ver los 
datos en un estilo orientado a objetos incluso si los 
datos están realmente almacenados en un formato 
relacional tradicional. 

• Métodos. Se pueden escribir en PL/SQL, Java o C. 

• Funciones de agregación definidas por el usua¬ 
rio. Se pueden utilizar en instrucciones SQL de la 
misma forma que las funciones incorporadas tales 
como sum y count. 

• Tipos de datos XML. Se pueden utilizar para 
almacenar e indexar documentos XML. 

Oracle tiene dos lenguajes procedimentales princi¬ 
pales, PL/SQL y Java. PL/SQL fue el lenguaje original 


de Oracle para los procedimientos almacenados y tiene 
una sintaxis similar al utilizado en el lenguaje Ada. Java 
se soporta mediante una máquina virtual Java dentro 
del motor de la base de datos. Oracle proporciona un 
paquete para encapsular procedimientos, funciones y 
variables relacionadas en unidades únicas. Oracle sopor¬ 
ta SQLJ (SQL incorporado en Java) y JDBC y propor¬ 
ciona una herramienta para generar las definiciones de 
clases Java correspondientes a tipos de la base de datos 
definidos por el usuario. 

25.2.2. Disparadores 

Oracle proporciona varios tipos de disparadores y 
varias opciones para el momento y forma en que se 
invocan (véase el Apartado 6.4 para una introducción 
a los disparadores en SQL). Los disparadores se pue¬ 
den escribir en PL/SQL o Java o como llamadas a C. 
Para los disparadores que se ejecutan sobre instruc¬ 
ciones LMD tales como insert, update y delete, Ora¬ 
cle soporta disparadores de filas (row) y disparadores 
de instrucciones (statement). Los disparadores de filas 
se pueden ejecutar una vez por cada fila que se vea 
afectada (actualización o borrado, por ejemplo) por la 
operación LMD. Un disparador de instrucciones se 
ejecuta solamente una vez por instrucción. En cada 
caso, el disparador se puede definir tanto como un dis¬ 
parador befare o after dependiendo de si se va a invo¬ 
car antes o después de que se lleva a cabo la operación 
LMD. 

Oracle permite la creación de disparadores instead 
of para las vistas que no pueden estar sujetas a opera¬ 
ciones LMD. Dependiendo de la definición de la vista 
puede no ser posible para Oracle traducir una instruc¬ 
ción LMD en una vista a modificaciones de las tablas 
base subyacentes sin ambigüedad. Por ello las opera¬ 
ciones LMD sobre vistas están sujetas a numerosas res¬ 
tricciones. Se puede crear un disparador instead of 
sobre una vista para especificar manualmente las ope¬ 
raciones sobre las tablas base que van a ocurrir en res¬ 
puesta a la operación LMD sobre la vista. Oracle eje¬ 
cuta el disparador en lugar de la operación LMD y por 
consiguiente proporciona un mecanismo de rodeo de 
las restricciones sobre las operaciones LMD sobre las 
vistas. 

Oracle también tiene disparadores que ejecutan otros 
eventos, tales como el inicio o finalización de la base 
de datos, mensajes de error del servidor, inicio o finali¬ 
zación de sesión de un usuario e instrucciones LDD tales 
como las instrucciones create, alter o drop. 
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25.3. ALMACENAMIENTO E INDEXACIÓN 


En la jerga de Oracle, una base de datos consiste en 
información almacenada en archivos y se accede a tra¬ 
vés de un ejemplar, que es un área de memoria com¬ 
partida y un conjunto de procesos que interactúa con 
los datos en los archivos. 

25.3.1. Espacios de tablas 

Una base de datos consiste en una o más unidades de 
almacenamiento lógicas denominadas espacios de 
tablas. Cada espacio de tablas, a su vez, consiste en una 
o más estructuras físicas denominadas archivos de 
datos. Éstos pueden ser archivos gestionados por el sis¬ 
tema operativo o dispositivos en bruto. 

Normalmente una base de datos Oracle tendrá los 
siguientes espacios de tablas: 

• El espacio de tablas del sistema, que siempre se 
crea. Contiene las tablas diccionario de datos y 
almacenamiento para los disparadores y los pro¬ 
cedimientos almacenados. 

• Espacios de tablas creados para almacenar los datos 
de usuario. Aunque los datos de usuario se pueden 
almacenar en el espacio de tablas del sistema es 
frecuentemente deseable separar los datos de usua¬ 
rio de los datos del sistema. Normalmente la deci¬ 
sión sobre los otros espacios de tablas que se deben 
crear está basada en el rendimiento, disponibili¬ 
dad, capacidad de mantenimiento y facilidad de 
administración. Por ejemplo, puede ser útil tener 
varios espacios de tablas para las operaciones de 
copia de seguridad parcial y recuperación. 

• Los espacios de tablas temporales. Muchas ope¬ 
raciones de base de datos requieren la ordenación 
de los datos y la rutina de ordenación puede tener 
que almacenar éstos temporalmente en el disco si 
la ordenación no se puede realizar en memoria. Se 
asignan espacios de tablas temporales a la orde¬ 
nación, para realizar las operaciones de gestión de 
espacio involucradas en un volcado a disco más 
eficiente. 

Los espacios de tablas también se pueden utilizar 
como un medio para trasladar datos entre las bases de 
datos. Por ejemplo, es común trasladar los datos desde 
un sistema transaccional a un almacén de datos a inter¬ 
valos regulares. Oracle permite trasladar todos los datos 
en un espacio de tablas de un sistema a otro sencilla¬ 
mente copiando los archivos y exportando e importan¬ 
do una pequeña cantidad de metadatos del diccionario 
de datos. Estas operaciones pueden ser mucho más rápi¬ 
das que descargar los datos de una base de datos y des¬ 
pués usar un descargador para insertarlos en la otra. Un 
requisito para esta característica es que ambos sistemas 
utilicen el mismo sistema operativo. 


25.3.2. Segmentos 

El espacio en un espacio de tablas se divide en unida¬ 
des, denominadas segmentos, cada una de las cuales 
contiene datos para una estructura de datos específica. 
Hay cuatro tipos de segmentos 

• Segmentos de datos. Cada tabla en un espacio de 
tablas tiene su propio segmento de datos donde se 
almacenan los datos de la tabla a menos que ésta 
se encuentre dividida; si esto ocurre, existe un seg¬ 
mento de datos por división (la división en Oracle 
se describe en el Apartado 25.3.10). 

• Segmentos de índices. Cada índice en un espacio 
de tablas posee su propio segmento de índices, 
excepto los índices divididos, los cuales mantie¬ 
nen un segmento de índices por división. 

• Segmentos temporales. Son segmentos utilizados 
cuando una operación de ordenación necesita escri¬ 
bir datos al disco o cuando éstos se insertan en una 
tabla temporal. 

• Segmentos de retroceso. Se trata de segmentos que 
contienen información para deshacer los cambios 
de las transacciones de forma que se pueda desha¬ 
cer una copia no terminada. También juegan un 
papel importante en el modelo de control de con¬ 
currencia en Oracle y para la recuperación de la base 
de datos, descrito en los Apartados 25.5.1 y 25.5.2. 

Debajo del nivel de segmentos se asigna espacio a 
un nivel de granularidad, denominado extensión. Cada 
extensión consiste en un conjunto de bloques contiguos 
de la base de datos. Un bloque de la base de datos es el 
nivel más bajo de granularidad en el cual Oracle ejecu¬ 
ta E/S a disco. Un bloque de base de la base de datos 
no tiene que tener el mismo tamaño que un bloque de 
un sistema operativo, pero debería ser un múltiplo. 

Oracle proporciona parámetros de almacenamiento 
que permiten un control detallado de cómo se asigna y 
gestiona el espacio, tales como: 

• El tamaño de una extensión nueva que se va a asig¬ 
nar para proporcionar espacio a las filas que se 
insertan en una tabla. 

• El porcentaje de utilización de espacio con el cual 
un bloque de la base de datos se considera lleno y 
con el cual no se introducirán más filas en ese blo¬ 
que (dejando algo de espacio libre en un bloque se 
puede permitir que las filas existentes aumenten su 
tamaño cuando se realizan actualizaciones sin que¬ 
darnos sin espacio en el bloque). 

25.3.3. Tablas 

Una tabla estándar en Oracle está organizada en mon¬ 
tículo; esto es, la ubicación de almacenamiento de una 
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fila en una tabla no está basada en los valores conteni¬ 
dos en la fila y se fija cuando la fila se inserta. Sin embar¬ 
go, si la tabla se divide, el contexto de la fila afecta a la 
partición en la cual está almacenada. Hay varias carac¬ 
terísticas y variaciones. Oracle soporta las tablas ani¬ 
dadas; esto es, una tabla puede tener una columna cuyo 
tipo de datos sea otra tabla. La tabla anidada no se alma¬ 
cena en línea en la tabla padre sino que se almacena en 
una tabla separada. 

Oracle soporta tablas temporales donde la duración 
de los datos es la de la transacción en la cual se inser¬ 
tan los datos o la sesión de usuario. Los datos son pri¬ 
vados a la sesión y se eliminan automáticamente al final 
de su duración. 

Una agrupación es otra forma de organización de los 
datos de la tabla (véase el Apartado 11.7). El concepto, 
en este contexto, no se debería confundir con otros sig¬ 
nificados de la palabra agrupación, tales como los rela¬ 
cionados con la arquitectura del ordenador. En una agru¬ 
pación las filas de tablas diferentes se almacenan juntas 
en el mismo bloque según algunas columnas comunes. 
Por ejemplo, una tabla de departamento y una tabla de 
empleados se podrían agrupar de forma que cada fila en 
la tabla departamento se almacene junto con todas las 
filas de los empleados que trabajan en ese departamen¬ 
to. Los valores de la clave principal o clave externa se 
utilizan para determinar la ubicación de almacenamien¬ 
to. Esta organización mejora el rendimiento cuando las 
dos tablas están combinadas pero sin un aumento de 
espacio de un esquema desnormalizado puesto que los 
valores en la tabla de departamento no están repetidos 
para cada empleado. Como compromiso, una consulta 
que involucra solamente la tabla departamento puede 
tener que involucrar un número sustancialmente más 
grande de bloques que si la tabla se almacenara sola. 

La organización en agrupación implica que una fila 
pertenece a un lugar específico; por ejemplo, una nue¬ 
va fila de empleado se debe insertar con las otras filas 
para el mismo departamento. Por consiguiente, es obli¬ 
gatorio un índice en la columna de agrupación. Una 
organización alternativa es una agrupación asociativa. 
Aquí, Oracle calcula la localización de una fila apli¬ 
cando una función asociativa al valor para la columna 
de agrupación. La función asociativa asigna la fila a un 
bloque específico en la agrupación asociativa. Puesto 
que no es necesario el recorrido del índice para acceder 
a una fila según su valor de columna de agrupación, esta 
organización puede ahorrar cantidades significativas de 
E/S a disco. Sin embargo, el número de cajones aso¬ 
ciativos y otros parámetros de almacenamiento se deben 
establecer cuidadosamente para evitar problemas de ren¬ 
dimiento debido a demasiadas colisiones o malgasto de 
espacio debido a cajones asociativos vacíos. 

La organización según agrupación asociativa y según 
agrupación normal se puede aplicar a una única tabla. El 
almacenamiento de una tabla como una agrupación aso¬ 
ciativa con la columna de la clave principal como la cla¬ 
ve de la agrupación puede permitir un acceso basado en 


un valor de clave principal con una única E/S a disco siem¬ 
pre que no haya desbordamiento para ese bloque de datos. 

25.3.4. Tablas organizadas con índices 

En una tabla organizada con índices los registros se alma¬ 
cenan en un índice de árbol B en lugar de en un mon¬ 
tículo. Una tabla organizada con índices requiere que se 
identifique una clave única para su uso como la clave del 
índice. Aunque una entrada en un índice normal contie¬ 
ne el valor de la clave y el identificador de fila de la fila 
indexada, una tabla organizada con índices reemplaza el 
identificador de fila con los valores de la columna para 
el resto de columnas en la tabla. Comparado con el alma¬ 
cenamiento de los datos en una tabla en montículo nor¬ 
mal y la creación de un índice según las columnas clave, 
una tabla organizada con índices puede mejorar el ren¬ 
dimiento y el espacio. Consideremos la lectura de todos 
los valores de columna de una fila, dado su valor de cla¬ 
ve principal. Para una tabla en montículo se requeriría un 
examen del índice seguido por un acceso a tabla median¬ 
te identificador de fila. Para una tabla organizada con 
índices solamente es necesario el examen del índice. 

Los índices secundarios sobre columnas que no sean 
clave de una tabla organizada con índices son distintos 
de los índices en una tabla en montículo normal. En una 
tabla en montículo cada fila posee un identificador de 
fila fijo que no cambia. Sin embargo, un árbol B se reor¬ 
ganiza al crecer o disminuir cuando se insertan o borran 
las entradas, y no hay garantía de que una fila perma¬ 
nezca en una ubicación dentro de una tabla organizada 
con índices. Por ello, un índice secundario en una tabla 
organizada con índices no contiene identificadores de 
fila normales, sino identificadores lógicos de fila. Un 
identificador lógico de fila se compone de dos partes: un 
identificador de fila física correspondiente a donde la fila 
estaba cuando se creó el índice o la última reconstruc¬ 
ción y un valor para la clave única. El identificador de 
fila física se conoce como una «suposición», puesto que 
sería incorrecto si la fila se ha trasladado. En este caso, 
la otra parte del identificador lógico de fila, el valor de 
la clave para la fila, se utiliza para acceder a la misma; 
sin embargo, este acceso es más lento que si la suposi¬ 
ción hubiera sido correcta, puesto que involucra un reco¬ 
rrido del árbol B para la tabla organizada con índices 
desde la raíz hasta los nodos hoja, incurriendo poten¬ 
cialmente en varias operaciones E/S de disco. Sin embar¬ 
go, si una tabla es altamente volátil y es probable que un 
buen porcentaje de suposiciones sean incorrectas, pue¬ 
de ser mejor crear un índice secundario con solamente 
valores clave, puesto que el uso de una suposición inco¬ 
rrecta puede producir una E/S a disco malgastada. 

25.3.5. índices 

Oracle soporta varios tipos distintos de índices. El tipo 
más comúnmente utilizado es un índice de árbol B, 
creado en una o varias columnas. (Nota: En la termi- 
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nología de Oracle, como también en varios otros siste¬ 
mas de bases de datos, un índice de árbol B es lo que se 
denomina un índice de árbol B+ en el Capítulo 12.) Las 
entradas de los índices tienen el siguiente formato: para 
un índice en las columnas col x , col 2 y coI 3 , cada fila en 
la tabla en donde al menos una columna tenga un valor 
no nulo resultaría en la entrada de índice 

<coI t > < coI 2 > < col¡ > < id-fila > 

donde < col¡ > denota el valor para la columna i e < id- 
fila > es la identificador de fila para la fila. Oracle pue¬ 
de opcionalmente comprimir el prefijo de la entrada para 
ahorrar espacio. Por ejemplo, si hay muchas combina¬ 
ciones repetidas de valores < col x > < col 2 >, la repre¬ 
sentación de cada prefijo < col x > < col 2 > distinto se 
puede compartir entre las entradas que tienen esa com¬ 
binación de valores, en lugar de almacenarlo explícita¬ 
mente para cada entrada. La compresión de prefijos pue¬ 
de llevar a ahorros de espacio sustanciales. 

25.3.6. índices de mapas de bits 

Los índices de mapas de bits (descritos en el Apartado 
12.9.4) utilizan una representación de mapa de bits para 
entradas de índice que pueden llevar a un ahorro sus¬ 
tancial de espacio (y, por consiguiente, ahorro de E/S a 
disco), cuando la columna indexada tiene un número 
moderado de valores distintos. Los índices de mapas de 
bits en Oracle utilizan la misma clase de estructura de 
árbol B para almacenar las entradas que un índice nor¬ 
mal. Sin embargo, donde un índice normal en una colum¬ 
na tuviera entradas de la forma < col x > < id-fila >, una 
entrada de índice de mapa de bits tendría la forma 

< col, > < id-filainicial > < id-filafinal > 

< mapabitscomprimido >. 

El mapa de bits conceptualmente representa el espacio 
de todas las filas posibles en la tabla entre los identifi- 
cadores de la fila inicial y final. El número de tales filas 
posibles en un bloque depende de cuántas de ellas se 
pueden alojar en un bloque, lo cual va en función del 
número de columnas en la tabla y sus tipos de datos. 
Cada bit en el mapa de bits representa una fila posible 
en un bloque. Si el valor de la columna de esa fila es el 
de la entrada de índice, el bit se establece a 1. Si la fila 
tiene algún otro valor o la fila no existe realmente en la 
tabla, el bit se establece a 0 (es posible que la fila no 
exista realmente porque un bloque de la tabla pueda 
tener un número más pequeño de filas que el número 
que se calculó como el máximo posible). Si la diferen¬ 
cia es grande, el resultado pueden ser grandes cadenas 
de ceros consecutivos en el mapa de bits, pero el algo¬ 
ritmo de compresión trata dichas cadenas de ceros, por 
lo que el efecto negativo se limita. 

El algoritmo de compresión es una variación de una 
técnica de compresión denominada compresión de 


mapas de bits alineados (Byte-Aligned Bitmap Com- 
pression, BBC). Esencialmente, una sección del mapa 
de bits donde la distancia entre dos unos consecutivos es 
suficientemente pequeña se almacena como mapas de 
bits. Si la distancia entre dos unos es suficientemente 
grande (esto es, hay un número suficiente de ceros entre 
ellos) se almacena el número de ceros. 

Los índices de mapas de bits permiten varios índi¬ 
ces en la misma tabla para combinarse en la misma ruta 
de acceso si hay varias condiciones sobre las columnas 
indexadas en la cláusula where de una consulta. Por 
ejemplo, para la condición 

(■ co /j = 1 or col x = 2) and col 2 > 5 and col 3 o 10 

Oracle podría calcular las filas que coinciden con la con¬ 
dición ejecutando operaciones booleanas sobre los 
mapas de bits a partir los mapas de bits de índices sobre 
las tres columnas. En este caso, estas operaciones se 
realizarían para cada índice: 

• Para el índice en col t , se realizaría la disyunción 
de los valores de clave 1 y 2. 

• Para el índice en coI 2 , todos los mapas de bits para 
los valores de la clave > 5 se mezclarían en una 
operación que corresponde a una disyunción. 

• Para el índice en col v se obtendrían los mapas de 
bits para los valores 10 y nuil. Entonces, se apli¬ 
caría una conjunción sobre los resultados de los 
dos primeros índices, seguido por dos operaciones 
menos booleanas de los mapas de bits para los 
valores 10 y nuil para col 3 . 

Todas las operaciones se realizan directamente sobre la 
representación comprimida de los mapas de bits (no es 
necesaria la descompresión) y el mapa de bits resultan¬ 
te (comprimido) representa las filas que cumplen todas 
las condiciones lógicas. 

La capacidad de utilizar las operaciones booleanas 
para combinar varios índices no está limitada a los índi¬ 
ces de mapas de bits. Oracle puede convertir identifi- 
cadores de filas a la representación de mapa de bits com¬ 
primidos, por lo que se puede utilizar un índice de árbol 
B normal en cualquier lugar de un árbol binario u ope¬ 
ración de mapa de bits simplemente poniendo un ope¬ 
rador id-fila-a-mapa-de-bits en la parte superior del acce¬ 
so a índices del plan de ejecución. 

Como regla nemotécnica, los índices de mapas de 
bits tienden a ser más eficientes en el espacio que los 
índices de árbol B si el número de valores distintos de 
la clave es menor que la mitad del número de filas en 
una tabla. Por ejemplo, en una tabla con un millón de 
filas, un índice en una columna con menos de 500.000 
valores distintos probablemente sería menor si se crea¬ 
ra como un índice de mapa de bits. Para las columnas 
con un número muy pequeño de valores distintos (por 
ejemplo, las columnas que se refieren a propiedades 
tales como país, estado, género, estado marital y varios 


616 


CAPÍTULO 25 ORACLE 


estados indicadores) un índice mapa de bits podría 
requerir solamente una pequeña fracción del espacio 
normal de un índice de árbol B normal. Cualquier ven¬ 
taja en el espacio también puede dar lugar a mejoras en 
el rendimiento en la forma de menos operaciones E/S a 
disco cuando se explora el índice. 

25.3.7. índices basados en funciones 

Además de crear índices sobre una o varias columnas 
de una tabla. Oracle permite crear índices sobre expre¬ 
siones que involucran una o más columnas, tales como 
col { + col 2 * 5. Por ejemplo, la creación de un índice 
sobre la expresión upper {nombre), donde upper es una 
función que devuelve la versión en mayúsculas de una 
cadena y nombre es una columna, es posible realizar 
búsquedas independientes de la caja (mayúsculas o 
minúsculas) sobre la columna nombre. Con el fin de 
buscar todas las filas con el nombre «van Gogh» de una 
forma eficiente se puede utilizar la condición 

upper{nombre )-’VAN GOGH’ 

en la cláusula where de la consulta. Oracle entonces 
casa la condición con la definición de índice y conclu¬ 
ye que se puede utilizar el índice para recuperar todas 
las filas que coincidan con «van Gogh» sin considerar 
las mayúsculas y minúsculas del nombre cuando se 
almacenó en la base de datos. Se puede crear un índice 
basado en función como un mapa de bits o como un 
índice de árbol B. 

25.3.8. índices de reunión 

Un índice de reunión es un índice donde las columnas 
clave no están en la tabla que se referencia mediante los 
identificadores de filas en el índice. Oracle soporta los 
índices de reunión mapa de bits principalmente para su 
uso con esquemas en estrella (véase el Apartado 22.4.2). 
Por ejemplo, si hay una columna para los nombres de 
los productos en una tabla de la dimensión productos 
se podría utilizar un índice de reunión de mapas de bits 
sobre la tabla de hechos con esta columna clave para 
recuperar las filas de la tabla de hechos que correspon¬ 
den a un producto con un nombre específico, aunque el 
nombre no esté almacenado en la tabla de hechos. La 
forma en la que las filas en las tablas de hechos y de la 
dimensión correspondientes está basada en una condi¬ 
ción de reunión se especifica cuando se crea el índice y 
se convierte en parte de los los metadatos de índices. 
Cuando se procesa una consulta el optimizador busca¬ 
rá la misma condición de reunión en la cláusula where 
de la consulta con el fin de determinar si es aplicable el 
índice de reunión. 

Oracle permite índices de reunión de mapa de bits 
para tener más de una columna clave y estas columnas 
pueden estar en tablas diferentes. En todos los casos las 
condiciones de reunión entre la tabla de hechos donde 


se construye el índice y las tablas dimensionales se 
deben referir a claves únicas en las tablas dimensiona¬ 
les; esto es, una fila indexada en la tabla de hechos debe 
corresponder a una única fila en cada una de las tablas 
de dimensión. 

Oracle puede combinar un índice de reunión de mapa 
de bits en una tabla de hechos con otros índices en la 
misma tabla (tanto si hay índices de reunión o no) 
mediante el uso de operadores para las operaciones boo- 
leanas del mapa de bits. Por ejemplo, consideremos un 
esquema con una tabla de hechos para las ventas y tablas 
dimensionales para los clientes, productos y fechas. 
Supongamos que una consulta solicita información sobre 
las ventas a los clientes en un cierto código postal que 
compraron productos de una cierta categoría de pro¬ 
ducto durante un cierto periodo de tiempo. Si existe un 
índice de reunión de mapa de bits sobre varias colum¬ 
nas donde las columnas clave son las columnas de la 
tabla de dimensión restringidas (código postal, catego¬ 
ría de producto y fecha), Oracle puede utilizar el índi¬ 
ce de reunión para buscar las filas en la tabla de hechos 
que coinciden con las condiciones de restricción. Sin 
embargo, si existen índices individuales sobre una úni¬ 
ca columna para las columnas clave (o un subconjunto 
de ellas), Oracle puede recuperar los mapas de bits de 
las filas de la tabla de hechos que coinciden con cada 
condición individual y utiliza la operación and boo- 
leana para generar un mapa de bits de la tabla de hechos 
para aquellas filas que satisfacen todas las condiciones. 
Si la consulta contiene condiciones sobre algunas colum¬ 
nas de la tabla de hechos, los índices de aquellas colum¬ 
nas se podrían incluir en la misma ruta de acceso, inclu¬ 
so si fueran índices normales de árbol B o índices de 
dominio (los índices de dominio se describen poste¬ 
riormente en el Apartado 25.3.9). 

25.3.9. índices de dominio 

Oracle permite que las tablas sean indexadas por estruc¬ 
turas de índices que no sean propias de Oracle. Esta 
característica de extensibilidad del servidor Oracle per¬ 
mite a los fabricantes de software desarrollar los lla¬ 
mados cartuchos con funcionalidad para dominios de 
aplicación específicos, tales como texto, datos espacia¬ 
les e imágenes, con la funcionalidad de indexado más 
allá de la proporcionada por los tipos de índice Oracle 
estándar. Para implementar la lógica para crear, mante¬ 
ner y buscar en el índice, el diseñador de índices debe 
asegurar que se adhiere a un protocolo específico en su 
interacción con el servidor Oracle. 

Un índice de dominio se debe registrar en el diccio¬ 
nario de datos junto con los operadores que soporta. El 
optimizador de Oracle considera los índices de domi¬ 
nio como una de las posibles rutas de acceso para una 
tabla. Oracle permite a las funciones de coste registrar¬ 
se con los operadores de forma que el optimizador pue¬ 
da comparar el coste del uso del índice de dominio con 
los de otras mtas de acceso. 
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Por ejemplo, un índice de dominio para búsquedas 
de texto avanzadas puede soportar un operador contains 
(contiene). Una vez que se ha registrado este operador, 
el índice de dominio se considerará como una ruta de 
acceso para una consulta como 

select * 

from empleados 

where contains{resumen, 'LINUX’) 

donde resumen es una columna de texto en la tabla 
empleados. El índice de dominio se puede almacenar en 
un archivo de datos externo o dentro de una tabla Ora¬ 
cle organizada con índices. Un índice de dominio se pue¬ 
de combinar con otros índices (mapa de bits o de árbol 
B) en la misma ruta de acceso con la conversión entre 
la representación de mapa de bits y el identificador de 
fila y usando operaciones booleanas del mapa de bits. 

25.3.10. División en particiones 

Oracle soporta varias clases de división horizontal de 
tablas e índices y esta característica tiene una función 
principal en la capacidad de Oracle de soportar bases 
de datos muy grandes. La capacidad de dividir una tabla 
o índice tiene ventajas en muchas áreas. 

• La copia de seguridad y recuperación es más sen¬ 
cilla y rápida, puesto que se puede realizar sobre 
particiones individuales en lugar de sobre toda la 
tabla. 

• Las operaciones de carga en un entorno de alma¬ 
cén de datos son menos intrusivas: se pueden agre¬ 
gar datos a una partición y entonces agregar la 
partición a una tabla, lo que es una operación ins¬ 
tantánea. De igual forma, eliminar una partición 
con datos obsoletos desde una tabla es muy senci¬ 
llo en un almacén de datos que mantenga una ven¬ 
tana de datos históricos. 

• El rendimiento de la consulta se mejora sustan¬ 
cialmente, puesto que el optimizador puede reco¬ 
nocer que solamente se tiene que acceder a un sub¬ 
conjunto de las particiones de una tabla con el fin 
de resolver la consulta (poda de particiones). Tam¬ 
bién el optimizador puede reconocer que en una 
reunión no es necesario intentar hacer correspon¬ 
der todas las filas en una tabla con todas las filas 
en la otra, pero que las reuniones se necesitan rea¬ 
lizar solamente entre pares coincidentes de divi¬ 
siones (reunión por particiones). 

Cada fila en una tabla dividida está asociada con una 
partición específica. Esta asociación está basada en la 
columna o columnas de la división que son parte de la 
definición de una tabla dividida. Hay varias formas para 
hacer corresponder valores de columna a divisiones, 
dando lugar a varios tipos de divisiones, cada una con 
distintas características: divisiones por rangos, asocia¬ 
tivas, compuestas y por listas. 


25.3.10.1. División por rangos 

En la división por rangos los criterios de división son 
rangos de valores. Este tipo de división está especial¬ 
mente indicado para columnas de fechas, en cuyo caso 
todas las filas en el mismo rango de fechas, digamos un 
día o un mes, pertenecen a la misma partición. En un 
almacén de datos donde los datos se cargan desde sis¬ 
temas transaccionales a intervalos regulares, la división 
por rangos se puede utilizar para implementar eficien¬ 
temente una ventana de datos históricos. 

Cada carga de datos obtiene su nueva propia parti¬ 
ción, haciendo que el proceso de carga sea más rápido 
y eficiente. El sistema realmente carga los datos en una 
tabla separada con la misma definición de columna que 
en una tabla dividida. Se puede entonces verificar la 
consistencia de los datos, arreglarlos e indexarlos. Des¬ 
pués de eso el sistema puede hace de la tabla separada 
una nueva partición de la tabla partida mediante un sen¬ 
cillo cambio de los metadatos en el diccionario de datos 
(una operación casi instantánea). 

Mientras no cambien los metadatos, el proceso de 
carga no afecta a los datos existentes en la tabla dividi¬ 
da en ningún caso. No hay necesidad de realizar ningún 
mantenimiento de los índices existentes como parte de 
la carga. Los datos antiguos se pueden eliminar de una 
tabla sencillamente eliminando su partición; esta ope¬ 
ración no afecta al resto de particiones. Además, las con¬ 
sultas en un entorno de almacén de datos frecuentemente 
contienen condiciones que los restringen a un cierto 
periodo de tiempo, tal como una quincena o mes. Si se 
utiliza la división de datos por rangos el optimizador de 
consulta puede restringir el acceso a los datos de aque¬ 
llas particiones que son relevantes a la consulta y evi¬ 
tar una exploración de toda la tabla. 

25.3.10.2. División asociativa 

En la división asociativa, una función asociativa hace 
corresponder filas con divisiones según los valores en 
las columnas de la división. Este tipo de división resul¬ 
ta útil principalmente cuando es importante distribuir 
las filas equitativamente entre las particiones o cuando 
las reuniones por particiones son importantes para el 
rendimiento de la consulta. 

25.3.10.3. División compuesta 

En la división compuesta la tabla se divide por rangos, 
pero cada partición tiene subparticiones mediante el 
uso de división asociativa. Este tipo de división com¬ 
bina las ventajas de la división por rangos y la división 
asociativa. 

25.3.10.4. División por listas 

En la división por listas los valores asociados con una 
partición particular están en una lista. Este tipo de divi¬ 
sión es útil si los datos en la columna de división tienen 
un conjunto relativamente pequeño de valores discre¬ 
tos. Por ejemplo, una tabla con una columna provincia 
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se puede partir implícitamente por región geográfica si 
cada lista de particiones tiene las provincias que perte¬ 
necen a la misma región. 

25.3.11. Vistas materializadas 

La característica de la vista materializada (véase el Apar¬ 
tado 3.5.1) permite almacenar el resultado de una con¬ 
sulta SQL y utilizarlo en un procesamiento posterior. 
Además, Oracle mantiene el resultado materializado, 
actualizándolo cuando se actualizan las tablas a las que 
se hicieron referencia en la consulta. Las vistas mate¬ 
rializadas se utilizan en el almacén de datos para ace¬ 
lerar el procesamiento de la consulta, pero esta tecno¬ 
logía también se utiliza para la réplica en entornos 
distribuidos y móviles. 

En el almacén de datos, un uso común de vistas mate¬ 
rializadas es resumir los datos. Por ejemplo, un tipo 
común de consulta solicita «la suma de las ventas de cada 
cuatrimestre durante los últimos dos años». El precálcu¬ 
lo de los resultados, o algún resultado parcial, de dicha 
consulta puede acelerar drásticamente el procesamiento 
de la consulta comparado a calcularlo desde cero con la 
agregación de todos los registros de ventas por detalle. 

Oracle soporta reescrituras automáticas de las con¬ 
sultas que aprovechan cualquier vista materializada útil 
cuando se resuelve una consulta. La reescritura consis¬ 
te en cambiar la consulta para utilizar la vista materia¬ 
lizada en lugar de las tablas originales en la consulta. 
Además, la reescritura puede agregar reuniones adicio¬ 
nales o procesamiento de agregación si son necesarias 
para obtener el resultado correcto. Por ejemplo, si una 
consulta necesita las ventas por cuatrimestre, la rees¬ 
critura puede aprovechar una vista que materializa las 
ventas por mes, añadiendo agregación adicional para 
abstraer los meses a cuatrimestres. Oracle tiene un tipo 
de objeto de metadatos denominado dimensión que per¬ 
mite las relaciones jerárquicas en las tablas a definir. 
Por ejemplo, una tabla de la dimensión temporal en un 
esquema en estrella Oracle puede definir un objeto de 


metadatos dimensión para especificar cómo se abstraen 
los días a meses, los meses a cuatrimestres, los cuatri¬ 
mestres a años y así sucesivamente. De igual forma se 
pueden especificar las propiedades jerárquicas relacio¬ 
nadas con la geografía, por ejemplo, cómo los distritos 
de ventas se abstraen a regiones. La lógica de la rees¬ 
critura de la consulta examina estas relaciones puesto 
que permite utilizar una vista materializada para clases 
más amplias de consultas. 

El objeto contenedor para una vista materializada es 
una tabla, lo que significa que una vista materializada 
se puede indexar, dividir o estar sujeta a otros contro¬ 
les para mejorar el rendimiento de la consulta. 

Cuando hay cambios en los datos de las tablas refe- 
renciadas en la consulta que define una vista materiali¬ 
zada se debe actualizar la vista materializada para refle¬ 
jar dichos cambios. Oracle soporta tanto la actualización 
completa de una vista materializada como una actuali¬ 
zación rápida incremental. En una actualización com¬ 
pleta Oracle vuelve a calcular la vista materializada des¬ 
de cero, lo cual puede ser la mejor opción si las tablas 
subyacentes han tenido cambios significativos, por ejem¬ 
plo, debidos a una carga masiva. En una actualización 
incremental Oracle actualiza la vista utilizando regis¬ 
tros que fueron cambiados en las tablas subyacentes; la 
actualización de la vista es inmediata, esto es, se eje¬ 
cuta como parte de la transacción que cambió las tablas 
subyacentes. La actualización incremental puede ser 
mejor si el número de filas que se han cambiado es 
pequeño. Hay algunas restricciones sobre las clases de 
consultas según las que una vista materializada se pue¬ 
de actualizar de forma incremental (y otras que indican 
si una vista materializada siquiera se puede crear). 

Una vista materializada es similar a un índice en el 
sentido que, aunque puede mejorar el rendimiento de la 
consulta, usa espacio, y su creación y mantenimiento con¬ 
sume recursos. Para ayudar a resolver este compromiso 
Oracle proporciona un paquete que puede aconsejar al 
usuario de las vistas materializadas más efectivas en el 
coste, dada una carga de trabajo particular como entrada. 


25.4. PROCESAMIENTO Y OPTIMIZACIÓN DE CONSULTAS 


Oracle soporta una gran variedad de técnicas de proce¬ 
samiento en su motor de procesamiento de consultas. 
Algunas de las más importantes se describen aquí bre¬ 
vemente. 

25.4.1. Métodos de ejecución 

Los datos se pueden acceder mediante una serie de 
métodos de acceso: 

• Exploración de tabla completa. El procesador de 
la consulta explora toda la tabla y obtiene infor¬ 


mación sobre los bloques que forman la tabla del 
mapa de extensión y explorando esos bloques. 

• Exploración de índices. El procesador crea una 
clave de comienzo y/o finalización a partir de las 
condiciones en la consulta y la utiliza para explo¬ 
rar una parte relevante del índice. Si hay colum¬ 
nas que se tienen que recuperar, que no son parte 
del índice, la exploración del índice sería seguida 
por un acceso a la tabla mediante el índice del iden- 
tificador de fila. Si no hay disponible ninguna cla¬ 
ve de inicio o parada la exploración sería una 
exploración de índice completa. 


619 









FUNDAMENTOS DE BASES DE DATOS 


• Exploración rápida completa de índices. El pro¬ 
cesador explora las extensiones de la misma for¬ 
ma que la extensión de tabla en una exploración 
de tabla completa. Si el índice contiene todas las 
columnas que se necesitan en el índice y no hay 
buenas claves de inicio y parada que puedan redu¬ 
cir significativamente esa porción del índice que 
se exploraría en una exploración de índices nor¬ 
mal, este método puede ser la forma más rápida de 
acceder a los datos. Esto es porque la exploración 
rápida completa aprovecha de forma completa la 
E/S de disco de varios bloques. Sin embargo, a 
diferencia de una exploración completa normal, 
que recorre los bloques hoja del índice en orden, 
una exploración rápida completa no garantiza que 
la salida preserve el orden del índice. 

• Reunión de índices. Si una consulta necesita 
solamente un pequeño subconjunto de columnas 
de una tabla ancha, pero ningún índice contiene 
todas estas columnas, el procesador puede utilizar 
una reunión de índices para generar la información 
relevante sin acceder a la tabla, reuniendo varios 
índices que contienen en conjunto las columnas 
necesarias. Ejecuta las reuniones como reunión por 
asociación sobre los identificadores de filas desde 
los distintos índices. 

• Acceso a agrupaciones y agrupaciones asocia¬ 
das. El procesador accede a los datos utilizando la 
clave de agrupación. 

Oracle tiene diversas formas de combinar informa¬ 
ción desde varios índices en una única ruta de acceso. 
Esta posibilidad permite varias condiciones en la cláu¬ 
sula where que se pueden utilizar conjuntamente para 
calcular el conjunto de resultados de la forma más efi¬ 
cientemente posible. La funcionalidad incluye la capa¬ 
cidad de ejecutar las operaciones booleanas conjunción, 
disyunción y diferencia sobre mapas de bits que repre¬ 
sentan los identificadores de filas. Hay también opera¬ 
dores que hacen corresponder una lista de identificado- 
res de filas con mapas de bits y viceversa, lo que permite 
que los índices de árbol B normales y los índices de 
mapas de bits utilicen la misma rata de acceso. Además, 
para muchas consultas que involucran count (*) en 
selecciones sobre una tabla el resultado se puede cal¬ 
cular simplemente contando los bits activados en el 
mapa de bits generado mediante la aplicación de las 
condiciones de la cláusula where sin acceder a la tabla. 

Oracle soporta varios tipos de reuniones en el motor 
de ejecución: reuniones internas, externas, semireunio- 
nes y antirreuniones (una antirreunión en Oracle devuel¬ 
ve las filas de la parte izquierda de la entrada que no 
coinciden con ninguna fila en la parte derecha de la entra¬ 
da; esta operación se denomina antisemirreunión en otros 
libros). Evalúa cada tipo de reunión mediante uno de los 
tres métodos: reunión por asociación, reunión por mez¬ 
cla-ordenación o reunión en bucle anidado. 


25.4.2. Optimización 

En el Capítulo 14 se ha discutido el tema general de la 
optimización de la consulta. Aquí discutimos la opti¬ 
mización en el contexto de Oracle. 

25.4.2.1. Transformaciones de consultas 

Oracle realiza la optimización de consultas en varios 
pasos. La mayoría de las técnicas relacionadas con las 
transformaciones de consultas y reescritura tienen lugar 
antes de la selección de la ruta de acceso, pero Oracle 
también soporta varios tipos de transformaciones de 
consultas basadas en el costo que generan un plan com¬ 
pleto y devuelven una estimación del costo para la ver¬ 
sión estándar de la consulta y otra que ha sufrido trans¬ 
formaciones avanzadas. No todas las técnicas de 
transformación de consultas tienen garantizado su bene¬ 
ficio para cada consulta, pero mediante la generación 
de una estimación del coste para el mejor plan sin y con 
la transformación aplicada, Oracle puede adoptar una 
decisión inteligente. 

Algunos de los tipos principales de transformaciones 
y reescrituras soportados por Oracle son los siguientes: 

• Mezcla de vistas. La referencia de la vista en una 
consulta es reemplazada por la definición de la vis¬ 
ta. Esta transformación no es aplicable a todas las 
vistas. 

• Mezcla compleja de vistas. Oracle ofrece esta 
característica para ciertas clases de vistas que no 
están sujetas a la mezcla normal de vistas puesto 
que tienen un group by o select distinct en la defi¬ 
nición de la vista. Si dicha vista se combina con 
otras tablas, Oracle puede conmutar las reuniones 
y la operación de ordenación utilizada por group 
by o distinct. 

• Subconsultas planas. Oracle tiene una serie de 
transformaciones que convierten varias clases de 
subconsultas en reuniones, semirreuniones o anti¬ 
rreuniones. 

• Reescritura de vistas materializadas. Oracle tie¬ 
ne la capacidad de reescribir una consulta auto¬ 
máticamente para aprovechar las vistas materia¬ 
lizadas. Si alguna parte de la consulta se puede 
casar con una vista materializada existente, Ora¬ 
cle puede remplazar esta parte de la consulta con 
una referencia a la tabla en la cual la vista está 
materializada. Si es necesario, Oracle agrega con¬ 
diciones de reunión u operaciones group by para 
preservar la semántica de la consulta. Si son apli¬ 
cables varias vistas materializadas, Oracle reco¬ 
ge la que reduce la mayor cantidad de datos que 
se tienen que procesar. Además, Oracle somete la 
consulta reescrita y la versión original al proceso 
completo de optimización produciendo un plan de 
ejecución y un coste asociado estimado para cada 
una. Oracle entonces decide si ejecutar la versión 
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original o la reescrita de la consulta según la esti¬ 
mación del coste. 

• Transformación en estrella. Oracle soporta una 
técnica para evaluar las consultas en esquemas en 
estrella, conocidas como transformación en estre¬ 
lla. Cuando una consulta contiene una reunión de 
una tabla de hechos con tablas dimensionales y 
selecciones sobre los atributos de las tablas dimen¬ 
sionales, la consulta se transforma borrando la con¬ 
dición de la reunión entre la tabla de hechos y las 
tablas dimensionales y remplazando la condición 
de selección en cada tabla dimensional por una 
subconsulta del formulario: 

tabla_de_liechos.th¡ in 

(select cp from tabla dimensional 
where ccondiciones sobre 
tabla dimensional¡ >) 

Se genera dicha subconsulta para cada tabla dimen¬ 
sional que tiene algún predicado restrictivo. Si la 
dimensión tiene un esquema en copo de nieve (véa¬ 
se el Apartado 22.4), la subconsulta contendrá una 
reunión de las tablas aplicables que forman la 
dimensión. 

Oracle utiliza los valores que son devueltos des¬ 
de cada subconsulta para probar un índice sobre la 
columna de la tabla de hechos correspondiente, 
obteniendo un mapa de bits como resultado. Los 
mapas de bits generados desde distintas subcon¬ 
sultas se combinan con una operación and de 
mapas de bits. El mapa de bits resultante se pue¬ 
de utilizar para acceder a las filas de las tablas de 
hechos coincidentes. Por ello, solamente se acce¬ 
derá a las filas en la tabla de hechos que coinciden 
simultáneamente en las condiciones de las dimen¬ 
siones restringidas. 

Tanto la decisión de si el uso de una subcon¬ 
sulta para una dimensión particular es ventajoso y 
la decisión de si la consulta reescrita es mejor que 
la original están basadas en la estimación de cos¬ 
te del optimizador. 

25.4.2.2. Selección de la ruta de acceso 

Oracle tiene un optimizador basado en el costo que 
determina el orden de la reunión, métodos de reunión y 
ratas de acceso. Cada operación que el optimizador con¬ 
sidera tiene una función de coste asociada y el optimi¬ 
zador intenta generar la combinación de operaciones 
que tiene el coste global menor. 

Para estimar el coste de una operación, el optimiza¬ 
dor considera las estadísticas que se han calculado para 
los objetos del esquema tales como tablas e índices. La 
estadística contiene información sobre el tamaño del 
objeto, la cardinalidad, la distribución de datos de las 
columnas de la tabla y cosas similares. Para la estadís¬ 
tica de columnas, Oracle soporta histogramas equili¬ 
brados en altura e histogramas de frecuencia. Para faci¬ 


litar la recogida de las estadísticas del optimizador, Ora¬ 
cle puede supervisar la actividad de la modificación 
sobre tablas y sigue la pista de aquellas tablas que han 
sido objeto de suficientes cambios como para que pue¬ 
da ser apropiado un nuevo cálculo de las estadísticas. 
Oracle también sigue las columnas que se utilizan en 
las cláusulas where de las consultas, lo que hace que 
sean candidatas potenciales para la creación del histo- 
grama. Con una única orden un usuario puede decir a 
Oracle que actualice las estadísticas para aquellas tablas 
que han sido suficientemente cambiadas. Oracle utiliza 
un muestreo para acelerar el proceso de recoger la nue¬ 
va estadística y elige de forma automática el menor por¬ 
centaje de la muestra que sea adecuado. También deter¬ 
mina si la distribución de las columnas marcadas merece 
la creación de histogramas; si la distribución está cerca 
de ser uniforme Oracle utiliza una representación más 
sencilla de la estadística de columnas. 

Oracle utiliza el coste de CPU y E/S en disco en el 
modelo de coste en el optimizador. Para equilibrar los 
dos componentes almacena las medidas sobre la velo¬ 
cidad de CPU y rendimiento de E/S de disco como par¬ 
te de la estadística del optimizador. El paquete de Ora¬ 
cle para recoger la estadística del optimizador calcula 
estas medidas. 

Para consultas que involucran un número no trivial 
de reuniones, el espacio de búsqueda es un tema para 
el optimizador de consultas. Oracle soluciona este tema 
de varias formas. El optimizador genera un orden ini¬ 
cial de la reunión y entonces decide sobre los mejores 
métodos de la reunión y rutas de acceso para ese orden 
de la reunión. Entonces cambia el orden de las tablas y 
determina los mejores métodos de reunión y rutas de 
acceso para el nuevo orden y así sucesivamente, guar¬ 
dando el mejor plan que se ha encontrado hasta enton¬ 
ces. Oracle mantiene pequeña la optimización si el 
número de los distintos órdenes de la reunión que se 
han considerado es tan grande que el tiempo gastado en 
el optimizador puede ser grande comparado con el que 
se gastaría para ejecutar el mejor plan encontrado has¬ 
ta entonces. Puesto que este corte depende del coste esti¬ 
mado para el mejor plan encontrado hasta entonces, es 
importante encontrar un buen plan pronto, de forma que 
el optimizador se pueda parar después de un pequeño 
número de órdenes de la reunión, resultando un mejor 
tiempo de respuesta. Oracle utiliza varias heurísticas 
para el orden inicial para aumentar la probabilidad de 
que el primer orden de reunión se considere bueno. 

Por cada orden de reunión que se considera, el opti¬ 
mizador puede hacer pasadas adicionales por las tablas 
para decidir los métodos de reunión y las ratas de acce¬ 
so. Tales pasadas adicionales capturarían efectos glo¬ 
bales colaterales específicos sobre la selección de la rata 
de acceso. Por ejemplo, una combinación específica de 
métodos de reunión y rutas de acceso pueden eliminar 
la necesidad de ejecutar una ordenación order by. Pues¬ 
to que tal efecto lateral global puede no ser obvio cuan¬ 
do se consideran localmente los costes de los distintos 
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métodos de reunión y de rutas de acceso, se utiliza una 
pasada separada que capture un efecto colateral espe¬ 
cífico para encontrar un posible plan de ejecución con 
un mejor coste conjunto. 

25.4.2.3. Poda de particiones 

Para tablas divididas el optimizador intenta ajustar las 
condiciones en la cláusula where de una consulta con 
el criterio de división de la tabla con el fin de evitar acce¬ 
der a particiones que no son necesarias para el resulta¬ 
do. Por ejemplo, si una tabla se divide por el rango de 
fechas y la consulta se restringe a datos entre dos fechas 
específicas, el optimizador determina las particiones que 
contienen los datos entre las fechas específicas y ase¬ 
gura que solamente se accede a dichas particiones. Este 
escenario es muy común y la aceleración puede ser dra¬ 
mática si solamente es necesario un pequeño subcon¬ 
junto de particiones. 

25.4.3. Ejecución en paralelo 

Oracle permite ejecutar en paralelo una única instruc¬ 
ción SQL mediante la división del trabajo entre varios 
procesos en una computadora multiprocesadora. Esta 
característica es especialmente útil para operaciones 
intensivas en cómputo que de otra forma se ejecutarían 
en un tiempo inaceptablemente largo. Ejemplos repre¬ 
sentativos son las consultas de apoyo para la toma de 
decisiones que necesitan procesar grandes cantidades 
de datos, cargas de datos en un almacén de datos y 
creación o reconstrucción de índices. 

Con el fin de lograr una buena aceleración median¬ 
te el paralelismo es importante que el trabajo involu¬ 
crado en la ejecución de la instrucción se divida en gra¬ 
nulos que se pueden procesar de forma independiente 
mediante los distintos procesadores en paralelo. Depen¬ 
diendo del tipo de operación Oracle tiene diversas for¬ 
mas de dividir el trabajo. 

Para operaciones que acceden a objetos base (tablas 
e índices) Oracle puede dividir el trabajo mediante tro¬ 
zos horizontales de datos. Para algunas operaciones tales 
como una exploración completa de una tabla, cada uno 
de dichos trozos puede ser un rango de bloques (cada 
proceso de consulta en paralelo explora la tabla desde 
el bloque al comienzo del rango hasta el bloque al final). 
Para otras operaciones en una tabla dividida, como la 
actualización y borrado, el trozo podría ser una parti¬ 
ción. Para inserciones en una tabla no dividida los datos 
a insertar se dividen de forma aleatoria entre los proce¬ 
sos en paralelo. 

Las reuniones se pueden realizar en paralelo de dis¬ 
tintas formas. Una forma es dividir una de las entradas 
a la reunión entre procesos paralelos y permitir que cada 
proceso reúna su trozo con la otra entrada de la reunión; 
éste es el método de reunión con fragmentos y réplicas 
del Apartado 20.5.2. Por ejemplo, si una tabla grande 
se reúne con una pequeña mediante una reunión por aso¬ 
ciación, Oracle divide la tabla grande entre los proce¬ 


sos y envía una copia de la tabla pequeña a cada pro¬ 
ceso, la cual entonces reúne su trozo con la tabla menor. 
Si ambas tablas son grandes sería prohibitivamente cos¬ 
toso enviar una de ellas a todos los procesos. En ese 
caso Oracle logra el paralelismo mediante la división 
de los datos entre los procesos mediante la asociación 
de los valores de las columnas de la reunión (el méto¬ 
do de reunión por asociación dividida del Apartado 
20.5.2.1). Cada tabla se explora en paralelo mediante 
un conjunto de procesos y cada fila en la salida se pasa 
a un proceso de un conjunto de procesos que van a eje¬ 
cutar la reunión. El proceso que obtiene la fila se deter¬ 
mina mediante una función de asociación sobre los valo¬ 
res de la columna de reunión. Por ello, cada proceso de 
reunión obtiene solamente las filas que podrían poten¬ 
cialmente coincidir y filas correspondientes no podrían 
ir a parar a diferentes procesos. 

Oracle organiza en paralelo las operaciones de orde¬ 
nación mediante los rangos de valores de la columna en 
la cual se ejecuta la ordenación (esto es, usando la orde¬ 
nación de división por rangos del Apartado 20.5.1). 
A cada proceso que participa en la ordenación se le en¬ 
vían filas con los valores en este rango y ordena las filas 
en su rango. Para maximizar las ventajas del paralelis¬ 
mo las filas se tienen que dividir lo más equitativamente 
posible entre los procesos en paralelo y entonces surge 
el problema de determinar las fronteras de rango que 
generan una buena distribución. Oracle soluciona el pro¬ 
blema mediante un muestreo dinámico de un subcon¬ 
junto de las filas en la entrada a la ordenación antes de 
decidir las fronteras del rango. 

25.4.3.1. Estructura del proceso 

Los procesos involucrados en la ejecución en paralelo 
de una instrucción SQL consisten en un proceso coor¬ 
dinador y una serie de procesos servidores en paralelo. 
El coordinador es responsable de asignar trabajos a los 
servidores en paralelo y de recoger y devolver los datos 
a los procesos del usuario que enviaron la instrucción. 
El grado de paralelismo es el número de procesos ser¬ 
vidores en paralelo que se asignan para ejecutar una 
operación primitiva como parte de la instrucción. El gra¬ 
do de paralelismo se determina mediante el optimiza¬ 
dor, pero se puede reducir dinámicamente si la carga en 
el sistema aumenta. 

Los servidores en paralelo operan sobre un modelo 
productor/consumidor. Cuando es necesario una secuen¬ 
cia de operaciones para procesar una instrucción, el 
conjunto productor de servidores ejecuta la primera ope¬ 
ración y pasa los datos resultantes al conjunto de con¬ 
sumidores. Por ejemplo, si una exploración de tabla 
completa es seguida por una ordenación y el grado de 
paralelismo es 12, habría 12 servidores productores que 
ejecutan la exploración de la tabla y pasan el resultado 
a 12 servidores consumidores que ejecutan la ordena¬ 
ción. Si es necesaria una operación posterior, como otra 
ordenación, las funciones de los dos conjuntos de ser¬ 
vidores se cambian. Los servidores que originalmente 
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ejecutaban la exploración de la tabla adoptan la función 
de consumidores de la salida producida por la primera 
ordenación y lo utilizan para ejecutar la segunda orde¬ 
nación. Por ello se realizan una secuencia de operacio¬ 
nes pasando los datos entre dos conjuntos de servido¬ 
res que alternan sus funciones como productores y 
consumidores. Los servidores se comunican entre sí 
mediante las memorias intermedias sobre hardware de 
memoria compartida y mediante las conexiones de red 
de alta velocidad sobre configuraciones MPP (sin com¬ 
partimiento) y sistemas agrupados (discos compartidos). 


Para sistemas sin compartimiento el coste para acce¬ 
der a los datos en el disco no es uniforme entre los pro¬ 
cesos. Un proceso que se ejecuta en un nodo que tiene 
acceso directo a un dispositivo puede procesar los datos 
sobre ese dispositivo más rápidamente que un proceso 
que tiene que recuperar los datos a través de la red. 
Oracle utiliza el conocimiento sobre la afinidad dispo¬ 
sitivo a nodo y dispositivo a proceso (esto es, la capa¬ 
cidad de acceder a los dispositivos directamente) cuan¬ 
do distribuye el trabajo entre servidores en ejecución 
paralela. 


25.5. CONTROL DE CONCURRENCIA Y RECUPERACIÓN 


Oracle soporta técnicas de control de concurrencia y 
recuperación que proporcionan una serie de caracterís¬ 
ticas útiles. 

25.5.1. Control de concurrencia 

El control de concurrencia multiversión de Oracle difie¬ 
re de los mecanismos de concurrencia utilizados por la 
mayoría de los fabricantes de bases de datos. Para las 
consultas de sólo lectura se proporcionan instantáneas 
consistentes en lectura, que son vistas de la base de datos 
tal como existía en un cierto momento, conteniendo 
todas las actualizaciones que se comprometieron hasta 
ese momento y no el resto. Por ello no se utilizan los 
bloqueos de lectura y las consultas de sólo lectura no 
interfieren con otra actividad de la base de datos en tér¬ 
minos de bloqueos (esto es básicamente el protocolo de 
bloqueo multiversión en dos fases descrito en el Apar¬ 
tado 16.5.2). 

Oracle soporta la consistencia de lectura en un nivel 
de instrucción y de transacción. Al comienzo de la eje¬ 
cución de una instrucción o transacción (dependiendo 
del nivel de consistencia que se utilice) Oracle deter¬ 
mina el número de cambio del sistema (System Chan- 
ge Number, SCN) actual. El SCN esencialmente actúa 
como una marca temporal donde el tiempo se mide en 
términos de compromisos de la base de datos en lugar 
del tiempo de reloj. 

Si en el curso de una consulta se encuentra que un 
bloque de datos tiene un SCN mayor que el que está sien¬ 
do asociado con la consulta, es evidente que se ha modi¬ 
ficado el bloque de datos después del SCN de la con¬ 
sulta original mediante alguna otra transacción y puede 
o no haberse comprometido. Por ello los datos en el blo¬ 
que no se pueden incluir en una vista consistente de la 
base de datos como existía a la hora del SCN de la con¬ 
sulta. En su lugar, se debe utilizar una versión anterior 
de los datos en el bloque; específicamente aquel que ten¬ 
ga el SCN mayor que no exceda el SCN de la consulta. 
Oracle recupera la versión de los datos desde el segmento 
de retroceso (los segmentos de retroceso se describen en 
el Apartado 25.5.2). Por ello, supuesto que el segmento 


de retroceso es lo suficientemente grande, Oracle puede 
devolver un resultado consistente de la consulta incluso 
si los datos se han modificado varias veces desde que 
comenzara la ejecución de la consulta. Si el bloque con 
el SCN deseado ya no existe en el segmento de retroce¬ 
so, la consulta devolverá un error. Habría una indicación 
de que el segmento de retroceso no se ha dimensionado 
adecuadamente, dada la actividad del sistema. 

En el modelo de concurrencia de Oracle las opera¬ 
ciones de lectura no bloquean las operaciones de escri¬ 
tura y las operaciones de escritura no bloquean las ope¬ 
raciones de lectura, una propiedad que permite un alto 
grado de concurrencia. En particular, el esquema per¬ 
mite consultas largas (por ejemplo consultas de infor¬ 
mes) para ejecutar en un sistema con una gran cantidad 
de actividad transaccional. Esta clase de escenario es 
normalmente problemático para sistemas de bases de 
datos donde las consultas utilizan bloqueos de lectura, 
puesto que la consulta puede fallar al adquirirlos o blo¬ 
quear grandes cantidades de datos por mucho tiempo 
evitando, por consiguiente, la actividad transaccional 
de los datos y reduciendo la concurrencia (una alterna¬ 
tiva que se utiliza en algunos sistemas es utilizar un gra¬ 
do inferior de consistencia, tal como la consistencia en 
grado dos, pero eso podría producir resultados incon¬ 
sistentes en la consulta). 

El modelo de concurrencia de Oracle se utiliza como 
base para la característica Flashback Query. Esta carac¬ 
terística permite a un usuario establecer un cierto núme¬ 
ro SCN o tiempo de reloj en su sesión y ejecutar con¬ 
sultas sobre los datos que existían en esa fecha (supuesto 
que los datos todavía existían en el segmento de retro¬ 
ceso). Normalmente en un sistema de bases de datos, 
una vez que se ha realizado el cambio no hay forma de 
retroceder al estado anterior de los datos a menos que 
se realicen restauraciones desde copias de seguridad. 
Sin embargo, la recuperación de una base de datos muy 
grande puede ser muy costosa, especialmente si el obje¬ 
tivo es solamente recuperar algunos datos que han sido 
borrados inadvertidamente por un usuario. La caracte¬ 
rística Flashback Query proporciona un mecanismo 
mucho más sencillo para tratar los errores del usuario. 
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Oracle soporta dos niveles de aislamiento ANS1/1SO 
«con compromiso de lectura» y «secuenciable». No hay 
soporte para lecturas no actualizadas, puesto que no 
existe necesidad. Los dos niveles de aislamiento corres¬ 
ponden a si se utiliza la consistencia de la lectura en el 
nivel de instrucción o en el nivel de transacción. El nivel 
se puede establecer para una sesión o una transacción 
individual. La consistencia de lectura en el nivel de la 
instrucción es el predeterminado. 

Oracle utiliza un bloqueo en el nivel de las filas. Las 
actualizaciones de distintas filas no entran en conflicto. 
Si dos escritores intentan modificar la misma fila, uno 
espera hasta que el otro comprometa o retroceda y enton¬ 
ces puede devolver un error de conflicto de escritura o 
seguir y modificar la fila. Los bloqueos se mantienen 
mientras dure la transacción. 

Además de los bloqueos en el nivel de las filas que 
evitan las inconsistencias debido a la actividad, el LMD 
de Oracle utiliza los bloqueos de tabla para evitar las 
inconsistencias debido a la actividad LDD. Estos blo¬ 
queos evitan que, por ejemplo, un usuario elimine una 
tabla mientras otro usuario tiene una transacción aún no 
comprometida que está accediendo a la tabla. Oracle no 
utiliza el dimensionamiento de bloqueos para convertir 
los bloqueos de filas a bloqueos de tabla con el propó¬ 
sito de su control de concurrencia normal. 

Oracle detecta los interbloqueos automáticamente y 
los resuelve retrocediendo una de las transacciones invo¬ 
lucradas en el interbloqueo. 

Oracle soporta transacciones autónomas que son tran¬ 
sacciones independientes generadas con otras transac¬ 
ciones. Cuando Oracle invoca a una transacción autó¬ 
noma genera una nueva transacción en un contexto 
separado. La nueva transacción se puede comprometer 
o retroceder antes de que el control vuelva a la transac¬ 
ción llamadora. Oracle soporta varios niveles de anida- 
miento de transacciones autónomas. 

25.5.2. Estructuras básicas de recuperación 

Con el fin de comprender cómo se recupera Oracle de 
un fallo, tal como una caída del disco, es importante 
comprender las características básicas que están invo¬ 
lucradas. Además de los archivos de datos que contie¬ 
nen las tablas e índices hay archivos de control, regis¬ 
tros históricos rehacer, registros históricos rehacer 
archivados y segmentos de retroceso. 

El archivo de control contiene varios metadatos que 
son necesarios para operar en la base de datos, inclu¬ 
yendo la información sobre las copias de seguridad. 

Oracle registra cualquier modificación transaccional 
de una memoria intermedia de la base de datos en el 
registro histórico rehacer, que consiste en dos o más 
archivos. Registra la modificación como parte de la ope¬ 
ración que la causa y sin considerar si la transacción 
finalmente se produce. Registra los cambios de los índi¬ 
ces y segmentos de retroceso así como los cambios a la 
tabla de datos. Cuando se llenan los registros históricos 


rehacer se archivan mediante uno o varios procesos en 
segundo plano (si la base de datos se ejecuta en modo 

archivelog). 

El segmento de retroceso contiene información sobre 
versiones anteriores de los datos (esto es, información 
para deshacer). Además de esta función en el modelo 
de consistencia de Oracle, la información se utiliza para 
restaurar la versión anterior de los datos cuando se des¬ 
hace una transacción que ha modificado los datos. 

Para poder recuperar un fallo de almacenamiento se 
debería realizar una copia de seguridad de los archivos 
de datos y archivos de control periódicamente. La fre¬ 
cuencia de la copia de seguridad determina el tiempo 
mayor de recuperación, puesto que lleva más tiempo 
la recuperación si la copia de seguridad es antigua. Ora¬ 
cle soporta copias de seguridad en caliente (copias de 
seguridad ejecutadas en una base de datos en línea que 
está sujeta a una actividad transaccional). Durante la 
recuperación de una copia de seguridad, Oracle ejecu¬ 
ta dos pasos para alcanzar un estado consistente de la 
base de datos como existía antes del fallo. En primer 
lugar Oracle rehace las transacciones aplicando los 
archivos históricos rehacer (archivados) a la copia de 
seguridad. Esta acción lleva a la base de datos a un esta¬ 
do que existía en la fecha del fallo, pero no necesaria¬ 
mente un estado consistente, puesto que los registros 
históricos deshacer incluyen datos no comprometidos. 
En segundo lugar, Oracle deshace las transacciones no 
comprometidas mediante el uso del segmento de retro¬ 
ceso. La base de datos está ahora en un estado consis¬ 
tente. 

La recuperación en una base de datos que ha sido 
objeto de una actividad transaccional grande debido a 
la ultima copia de seguridad puede ser costosa en tiem¬ 
po. Oracle soporta recuperación en paralelo en la cual 
se utilizan varios procesos para aplicar información de 
rehacer simultáneamente. Oracle proporciona una herra¬ 
mienta GUI, el gestor de recuperación, que automatiza 
la mayor parte de las tareas asociadas con copias de 
seguridad y recuperación. 

25.5.3. Bases de datos en espera gestionadas 

Para asegurar una alta disponibilidad, Oracle propor¬ 
ciona la característica bases de datos en espera gestio¬ 
nadas (esta característica es la misma que las copias de 
seguridad remotas, descrita en el Apartado 17.10). Una 
base de datos en espera es una copia de la base de datos 
normal que se instala en un sistema separado. Si ocurre 
un fallo catastrófico en el sistema principal el sistema 
en espera se activa y asume el control, minimizando el 
efecto del fallo en la disponibilidad. Oracle mantiene la 
base de datos en espera actualizada mediante la aplica¬ 
ción constante de archivos históricos rehacer archiva¬ 
dos que se envían desde la base de datos principal. La 
base de datos de seguridad se puede usar en línea en 
modo sólo lectura y utilizarla para informes y consul¬ 
tas para el apoyo a la toma de decisiones. 
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25.6. ARQUITECTURA DEL SISTEMA 


Siempre que una aplicación de base de datos ejecuta una 
instrucción SQL hay un proceso del sistema operativo 
que ejecuta código en el servidor de bases de datos. Ora¬ 
cle se puede configurar de forma que el proceso del sis¬ 
tema operativo esté dedicado exclusivamente a la ins¬ 
trucción que se está procesando o de forma que el proceso 
se pueda compartir entre varias instrucciones. La última 
configuración, conocida como servidor multienhebra- 
do, tiene propiedades diferentes respecto a la arquitec¬ 
tura del proceso y memoria. Se discutirá la arquitectura 
del servidor dedicado en primer lugar y posteriormente 
la arquitectura del servidor multienhebrado. 

25.6.1. Servidor dedicado: estructuras 
de memoria 

La memoria utilizada por Oracle se divide principal¬ 
mente en tres categorías: áreas de código software, área 
global del sistema (System Global Area, SGA) y el área 
global del programa (Program Global Area, PGA). 

Las áreas de código del sistema son las partes de la 
memoria donde reside el código del servidor Oracle. Se 
asigna un PGA para cada proceso para albergar sus datos 
locales e información de control. Esta área contiene 
espacio en pilas para diversos datos de la sesión y la 
memoria privada para la instrucción SQL que se está 
ejecutando. También contiene memoria para operacio¬ 
nes de ordenación y asociación que pueden ocurrir 
durante la evaluación de la instrucción. 

SGA es un área de memoria para estructuras que son 
compartidas entre los usuarios. Está formada por varias 
estructuras principales, incluyendo: 

• Caché de memoria intermedia: Esta caché man¬ 
tiene bloques de datos a los que se accede fre¬ 
cuentemente (tablas e índices) en memoria para 
reducir la necesidad de ejecutar E/S a disco físico. 
Se usa una política menos actualizada excepto para 
bloques accedidos durante una exploración de tabla 
completa. Sin embargo, Oracle permite crear varias 
colas de memoria intermedia que tienen distintos 
criterios para la datación de los datos. Algunas ope¬ 
raciones Oracle omiten la caché de memoria inter¬ 
media y leen los datos directamente del disco. 

• Memoria intermedia de registro histórico reha¬ 
cer. Esta memoria intermedia contiene la parte del 
registro histórico rehacer que no se ha escrito toda¬ 
vía en el disco. 

• Cola compartida. Oracle busca maximizar el 
número de usuarios que pueden utilizar la base de 
datos concurrentemente minimizando la cantidad 
de memoria que es necesaria para cada usuario. 
Un concepto importante en este contexto es la 
capacidad de compartir la representación interna 


de instrucciones SQL y el código procedimental 
escrito en PL/SQL. Cuando varios usuarios eje¬ 
cutan la misma instrucción SQL pueden compar¬ 
tir la mayoría de estructuras de datos que repre¬ 
sentan el plan de ejecución de la instrucción. 
Solamente los datos que son locales a cada invo¬ 
cación específica de la instrucción necesitan man¬ 
tenerse en una memoria privada. 

Las partes que se pueden compartir de las estructu¬ 
ras de datos que representan la instrucción SQL se alma¬ 
cenan en la cola compartida, incluyendo el texto de la 
instrucción. El almacenamiento en caché de instruc¬ 
ciones SQL en la cola compartida también se guarda en 
tiempo de compilación, puesto que una nueva invoca¬ 
ción de la instmcción que ya está almacenada en caché 
no tiene que pasar por el proceso de compilación com¬ 
pleto. La determinación de si una instrucción SQL es la 
misma que la existente en la cola compartida se basa en 
la coincidencia exacta del texto y el establecimiento de 
ciertos parámetros de sesión. Oracle puede remplazar 
automáticamente las constantes en una instrucción SQL 
con variables vinculadas; las consultas futuras que son 
iguales excepto por los valores de constantes coincidi¬ 
rán con la consulta anterior en la cola compartida. La 
cola compartida también contiene cachés para infor¬ 
mación de diccionario y diversas estructuras de control. 

25.6.2. Servidor dedicado: estructuras 
de proceso 

Hay dos tipos de procesos que ejecutan código servi¬ 
dor Oracle: procesos servidor que procesan instruc¬ 
ciones SQL y procesos en segundo plano que ejecutan 
diversas tareas administrativas relacionadas con el ren¬ 
dimiento. Algunos de estos procesos son opcionales y 
en algunos casos se pueden utilizar varios procesos del 
mismo tipo por razones del rendimiento. Algunos de 
los tipos más importantes de procesos en segundo pla¬ 
no son: 

• Escritor de la base de datos. Cuando una memo¬ 
ria intermedia se elimina de la caché de la memo¬ 
ria intermedia se debe volver a escribir en el dis¬ 
co si se ha modificado desde que se introdujo en 
la caché. 

Los procesos del escritor de la base de datos 
ejecutan esta tarea, lo que ayuda al rendimiento 
del sistema liberando espacio en la caché de la 
memoria intermedia. 

• Escritor del registro histórico. El escritor del 
registro histórico procesa las entradas de escritu¬ 
ra de la memoria intermedia del registro histórico 
rehacer al archivo del registro histórico rehacer en 
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el disco. También escribe un registro de compro¬ 
miso al disco siempre que se compromete una tran¬ 
sacción. 

• Punto de revisión. El proceso punto de revisión 
actualiza las cabeceras del archivo de datos cuan¬ 
do ocurre un punto de revisión. 

• Monitor del sistema. Este proceso realiza la recu¬ 
peración ante una caída en caso necesario. Tam¬ 
bién ejecuta cierta administración del espacio para 
reclamar espacio no utilizado en espacios tempo¬ 
rales. 

• Monitor de procesos. Este proceso ejecuta recu¬ 
peración de procesos para procesos del servidor 
que fallan, liberando recursos y ejecutando diver¬ 
sas operaciones de limpieza. 

• Recuperador. El proceso recuperador resuelve los 
fallos y dirige la limpieza de transacciones distri¬ 
buidas. 

• Archivador. El archivador copia el archivo de 
registro histórico rehacer en línea a un registro his¬ 
tórico rehacer cada vez que se llena el archivo de 
registro histórico en línea. 

25.6.3. Servidor multienhebrado 

La configuración de servidor multienhebrado aumenta 
el número de usuarios que un número dado de procesos 
servidor pueden soportar compartiendo los procesos ser¬ 
vidor entre las instrucciones. Difiere de la arquitectura 
de servidor dedicado en los siguientes aspectos princi¬ 
pales: 

• Un proceso de envío en segundo plano encamina 
las solicitudes de usuarios al siguiente proceso ser¬ 
vidor disponible. Al realizar esto utiliza una cola 
de solicitudes y una cola de respuestas en el SGA. 
El distribuidor pone una nueva solicitud en la cola 
de solicitudes donde será recogida por un proceso 
servidor. Un proceso servidor completa una soli¬ 
citud, pone el resultado en la cola de respuestas 
para ser recogida por el distribuidor y ser devuel¬ 
ta al usuario. 

• Puesto que un proceso servidor se comparte entre 
varias instrucciones SQL, Oracle no mantiene datos 


privados en el PGA. Almacena los datos específi¬ 
cos de la sesión en el SGA. 

25.6.4. Agrupaciones de aplicaciones reales 
de Oracle9i 

Las agrupaciones de aplicaciones reales de Oracle9i 
(Oracle9i Real Application Clusters) es una caracterís¬ 
tica que permite que varios ejemplares de Oracle se eje¬ 
cuten en la misma base de datos (recuérdese que, en ter¬ 
minología de Oracle, un ejemplar es la combinación de 
procesos en segundo plano y áreas de memoria). Esta 
característica permite a Oracle ejecutarse en arquitec¬ 
turas de hardware agrupadas y MPP (disco compartido 
y sin compartimiento). Esta característica se denominó 
servidor paralelo de Oracle (Oracle Parallel Server) en 
versiones anteriores de Oracle. La capacidad de agru¬ 
par varios nodos tiene importantes ventajas en la dimen- 
sionabilidad y disponibilidad que son útiles en entornos 
OLTP y de almacén de datos. 

Las ventajas de dimensionabilidad de la caracterís¬ 
tica son obvias, puesto que más nodos significa más 
potencia de procesamiento. Oracle optimiza más toda¬ 
vía el uso del hardware a través de las características 
tales como las reuniones por afinidad y por particiones. 

Las agmpaciones de aplicaciones reales de Oracle9i 
también se pueden utilizar para lograr una alta disponi¬ 
bilidad. Si un nodo falla, los restantes todavía están dis¬ 
ponibles para que la aplicación acceda a la base de datos. 
Las instancias restantes automáticamente retroceden las 
transacciones sin compromiso que están siendo proce¬ 
sadas en el nodo que falló con el fin de evitar un blo¬ 
queo de la actividad en el resto de nodos. 

La ejecución de varias instancias en la misma base 
de datos da lugar a varios temas técnicos que no exis¬ 
ten en un único ejemplar. Mientras que algunas veces 
es posible dividir una aplicación entre los nodos de for¬ 
ma que los nodos raramente accedan a los mismos datos, 
siempre hay posibilidad de solapamiento, que afecta a 
la gestión de los bloqueos y de la caché. Para solucio¬ 
nar esto Oracle soporta un gestor de bloqueos distri¬ 
buidos y la característica mezcla de cachés, que permi¬ 
te a los bloques de datos fluir directamente entre las 
cachés de distintos ejemplares mediante el uso de la 
interconexión, sin ser escritas a disco. 


25.7. RÉPLICAS, DISTRIBUCIÓN Y DATOS EXTERNOS 


Oracle proporciona soporte para las réplicas y transac¬ 
ciones distribuidas con compromiso de dos fases. 

25.7.1. Réplica 

Oracle soporta varios tipos de réplica (véase el Aparta¬ 
do 19.2.1 para una introducción a las réplicas). En su 


forma más sencilla los datos en un sitio maestro se dupli¬ 
can en otros sitios en forma de instantáneas (el término 
«instantánea» en este contexto no se debería confundir 
con el concepto de instantánea consistente en lectura en 
el contexto del modelo de concurrencia). Una instantá¬ 
nea no tiene que contener todos los datos maestros (pue¬ 
de, por ejemplo, excluir ciertas columnas de una tabla 
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por razones de seguridad). Oracle soporta dos tipos de 
instantáneas: sólo lectura y actualizable. Una instantá¬ 
nea actualizable se puede modificar en el sitio esclavo 
y las modificaciones se propagan hasta la tabla maes¬ 
tra. Sin embargo, las instantáneas sólo lectura permiten 
un rango más amplio de definiciones de instantánea. Por 
ejemplo, una instantánea de sólo lectura se puede defi¬ 
nir en términos de conjuntos de operaciones sobre tablas 
en el sitio maestro. Oracle también soporta varios sitios 
maestros para los mismos datos, donde todos los sitios 
maestros actúan como pares. Se puede actualizar una 
tabla replicada en cualquiera de los sitios maestro y la 
actualización se propaga al resto de sitios. Las actuali¬ 
zaciones se pueden propagar de forma asincrona o sin¬ 
crónica. 

Para la réplica asincrona la información de actua¬ 
lización se envía mediante procesos por lotes al resto 
de sitios maestros y entonces se aplican. Puesto que 
los mismos datos podrían estar sujetos a modificacio¬ 
nes conflictivas en sitios diferentes, se podría necesi¬ 
tar una resolución del conflicto basada en algunas 
reglas del negocio. Oracle proporciona una serie de 
métodos de resolución de conflictos incorporados y 
permite a los usuarios escribir el suyo propio si fuera 
necesario. 

Con la réplica asincrona, una actualización de un 
sitio maestro se propaga de forma inmediata al resto de 
sitios. Si falla la transacción de actualización en cual¬ 
quier sitio maestro, la actualización se deshace en todos 
los sitios. 

25.7.2. Bases de datos distribuidas 

Oracle soporta consultas y transacciones sobre varias 
bases de datos en distintos sistemas. Con el uso de 
pasarelas los sistemas remotos pueden incluir bases de 
datos que no sean de Oracle. Oracle tiene capacidades 
incorporadas para optimizar una consulta que incluya 
tablas en distintos sitios, recuperar los datos relevan¬ 
tes y devolver los resultados como si hubiera sido una 
consulta normal local. Oracle también soporta la emi¬ 
sión transparente de transacciones a varios sitios 
mediante un protocolo de compromiso en dos fases 
incorporado. 


25.7.3. Orígenes de datos externos 

Oracle tiene varios mecanismos para soportar orígenes 
de datos externos. El uso más común es el almacén de 
datos cuando se cargan normalmente grandes cantida¬ 
des de datos desde un sistema transaccional. 

25.7.3.1. SQL*Loader 

Oracle tiene una utilidad de carga directa, SQL*Loader, 
que soporta cargas rápidas en paralelo de grandes canti¬ 
dades de datos desde archivos extemos. Soporta una serie 
de formatos de datos y puede ejecutar varias operacio¬ 
nes de filtrado sobre los datos que se están cargando. 

25.7.3.2. Tablas externas 

Oracle permite hacer referencia a los orígenes de datos 
externos, tales como archivos planos, en la cláusula 
from de una consulta como si fueran tablas normales. 
Una tabla extema se define mediante metadatos que des¬ 
criben los tipos de columna Oracle y la corresponden¬ 
cia entre los datos externos y dichas columnas. Tam¬ 
bién es necesario un controlador de acceso para acceder 
a los datos externos. Oracle proporciona un controlador 
predeterminado para archivos planos. 

La característica de tabla externa tiene el objetivo 
principal de operaciones de extracción, transformación 
y carga (ETL) en un entorno de almacén de datos. Los 
datos se pueden cargar en el almacén de datos desde un 
archivo plano mediante el uso de 

create table tabla as 

select... from < tabla externa > 

where ... 

Mediante la agregación de operaciones sobre los 
datos en la lista select o cláusula where, se pueden rea¬ 
lizar transformaciones y filtrados como parte de la mis¬ 
ma instrucción SQL. Puesto que estas operaciones se 
pueden expresar en SQL nativo o en funciones escritas 
en PL/SQL o Java, la característica de tabla externa pro¬ 
porciona un mecanismo potente para expresar todas las 
clases de operaciones de transformación y filtrado de 
los datos. Para la dimensionabilidad, se puede realizar 
en paralelo el acceso a la tabla externa mediante la carac¬ 
terística de ejecución en paralelo de Oracle. 


25.8. HERRAMIENTAS DE GESTIÓN DE BASES DE DATOS 


Oracle proporciona a los usuarios una serie de herra¬ 
mientas para la gestión del sistema y desarrollo de apli¬ 
caciones. 

25.8.1. Gestor corporativo de Oracle 

El gestor corporativo de Oracle (Oracle Enterprise 
Manager) es la principal característica de Oracle para 


la gestión de sistemas de bases de datos. Proporciona 
una interfaz de usuario gráfica (GUI) sencilla de utili¬ 
zar y una serie de asistentes para la administración del 
esquema, de la seguridad, de los ejemplares, del alma¬ 
cenamiento y de la planificación de tareas. También pro¬ 
porciona la supervisión del rendimiento y herramientas 
para ayudar a los administradores a ajustar la aplicación 
SQL, rutas de acceso y parámetros de almacenamiento 
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de ejemplares y datos. Por ejemplo, incluye un asisten¬ 
te que puede sugerir los índices que son los más efecti¬ 
vos de crear bajo una carga de trabajo dada. 

25.8.2. Gestión de los recursos de la base 
de datos 

Un administrador de la base de datos necesita poder con¬ 
trolar cómo se divide la potencia de procesamiento entre 
los usuarios y grupos de usuarios. Algunos grupos pue¬ 
den ejecutar consultas interactivas donde el tiempo de 
respuesta es crítico; otros pueden ejecutar informes lar¬ 
gos que se pueden ejecutar como tareas de procesos por 
lotes en segundo plano cuando la carga del sistema sea 
baja. También es importante poder evitar que un usua¬ 
rio envíe inadvertidamente una consulta ad hoc extre¬ 
madamente costosa que retrasará demasiado al resto. 

La característica de gestión de los recursos de la base 
de datos de Oracle permite al administrador de la base 
de datos dividir los usuarios entre grupos consumido¬ 
res de recursos con distintas prioridades y propiedades. 


Por ejemplo, un grupo de usuarios interactivos de alta 
prioridad pueden tener garantizado al menos un 60 por 
ciento de UCP El resto, más alguna parte del 60 por 
ciento no utilizado por el grupo de alta prioridad, se 
asignaría entre los grupos de consumidores de recursos 
con baja prioridad. Un grupo de realmente baja priori¬ 
dad podría tener asignado un 0 por ciento, lo que sig¬ 
nificaría que las consultas enviadas por este grupo se 
ejecutarían solamente cuando hubiera disponibles ciclos 
de CPU no utilizados. Se pueden establecer para cada 
grupo límites para el grado de paralelismos para la eje¬ 
cución en paralelo. El administrador de la base de datos 
también puede establecer límites de tiempo sobre cuán¬ 
to tiempo máximo de ejecución se permite a una ins¬ 
trucción SQL. Cuando un usuario envía una instrucción, 
el gestor de recursos estima cuánto tiempo tardaría en 
ejecutarse y devuelve un error si la instrucción viola el 
límite. El gestor de recursos también puede limitar el 
número de sesiones de usuario que se pueden activar 
simultáneamente para cada grupo de consumidores de 
recursos. 


NOTAS BIBLIOGRÁFICAS 


Se puede encontrar información actualizada, inclu¬ 
yendo documentación, sobre productos Oracle en 
http://www.oracle.com y http://technet.oracle.com. La 
indexación extensible en Oracle8i se describe en Sri- 
nivasan et al. [2000b], mientras que Srinivasan et al. 
[2000a] describe las tablas organizadas con índices en 
Oracle8i. Banerjee et al. [2000] describe soporte XML 
en Oracle8i. Bello et al. [1998] describe las vistas mate¬ 


rializadas en Oracle. Antoshenkov [1995] describe la 
técnica de compresión de mapas de bits alineadas por 
bytes utilizada en Oracle; véase también Johnson 
[1999b]. Oracle Parallel Server se describe en Bam- 
ford et al. [1998]. La recuperación en Oracle viene des¬ 
crita por Joshi et al. [1998] y Lahiri et al. [2001]. La 
mensajería y las colas en Oracle se describen en Gaw- 
lick [1998], 
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VIII 


ESTUDIO DE CASOS 


E sta parte describe cómo los distintos sistemas de bases de datos integran 
los diferentes conceptos descritos anteriormente en el libro. Específica¬ 
mente, en los Capítulos 25, 26 y 27 se cubren tres sistemas de bases de 
datos ampliamente utilizados: DB2 de IBM, Oracle y SQL Server de Microsoft. 
Cada uno de estos capítulos muestra características únicas de cada sistema de 
bases de datos: herramientas, variaciones y extensiones de SQL y la arquitec¬ 
tura del sistema, incluyendo organización del almacenamiento, procesamiento 
de consultas, control de concurrencia y recuperación y réplicas. 

Los capítulos cubren solamente los aspectos clave de los productos de bases 
de datos que describen, y por consiguiente, no se deberían utilizar como una 
descripción completa del producto. Además, puesto que los productos se mejo¬ 
ran periódicamente, los detalles del producto pueden cambiar. Cuando se uti¬ 
liza una versión particular del producto hay que asegurarse de consultar los 
manuales de usuario para los detalles específicos. 

Hay que considerar que los capítulos en esta parte utilizan terminología 
industrial en lugar de académica. Por ejemplo, se utiliza tabla en lugar de 
relación, fila en lugar de tupia y columna en lugar de atributo. 


CAPÍTULO 



DB2 DE IBM 

SRIRAM PADMAN ABHAN 

IBM T. J. WATSON RESEARCH CENTER 


L a familia de productos DB2 Universal Database de IBM consiste en servidores de bases de datos 
y un conjunto de productos relacionados. DB2 Universal Database Server está disponible en 
muchas plataformas hardware y sistemas operativos, abarcando desde mainframes (grandes 
ordenadores centrales) y grandes servidores a estaciones de trabajo e incluso a pequeños dispositivos 
de bolsillo. Se ejecuta en una serie de sistemas operativos IBM y de otras marcas. Everyplace Edition 
soporta sistemas operativos tales como PalmOS, Windows CE y otros. Las aplicaciones pueden migrar 
fácilmente desde las plataformas de gama baja a servidores de gama alta. Además del motor del núcleo 
de la base de datos, la familia DB2 consta también de varios otros productos que proporcionan herra¬ 
mientas, administración, réplicas, acceso a datos distribuido, acceso a datos generalizados, OLAP y 
otras muchas características. En la Figura 26.1 se describen los diferentes productos en la familia. 

El origen de DB2 se remonta al proyecto System R en el Centro de Investigación de Almadén 
(Almadén Research Center) de IBM (entonces denominado Laboratorio de investigación de San 
José de IBM, IBM San José Research Laboratory). El primer producto DB2 se lanzó en 1984 sobre 
la plataforma mainframe de IBM. Fue seguido por otras versiones para otras plataformas. IBM ha 
mejorado continuamente el producto DB2 en áreas tales como procesamiento de transacciones 
(registro histórico de escritura anticipada y los algoritmos de recuperación ARIES), procesamiento 
y optimización de consultas (proyecto de investigación Starburst), procesamiento en paralelo (DB2 
Parallel Edition), soporte para bases de datos activas (restricciones y disparadores) y soporte rela- 
cional orientado a objetos aprovechando las innovaciones de su división de investigación. Se pue¬ 
den ver las notas bibliográficas para referencias que proporcionan más detalles. 

El motor de la base de datos DB2 está disponible en cuatro bases de código diferentes: (1) 
OS/390, (2) VM, (3) AS/400 y (4) resto de plataformas. Los elementos comunes en todas estas 
bases de código son interfaces extemas (en concreto el lenguaje de definición de datos (LDD) y 
SQL) y herramientas básicas tales como administración. Sin embargo, existen diferencias como 
resultado de diferentes historias de desarrollo para las bases de código. El resto de este capítulo se 
enfocará en DB2 Universal Database System de plataformas Unix, Windows y OS/2. Se reseña¬ 
rán las características específicas de interés en otros sistemas DB2 cuando se considere apropiado. 


Servidores de bases de datos 

DB2 UDB para Unix, Windows, OS/2, Linux 
DB2 UDB para OS/390 
DB2 UDB para AS/400 
DB2 para VMA/SE 

Desarrollo de aplicaciones 
VisualAge para Java, C++ 

VisualAge Generator 
DB2 Forms para OS/390 
Lotus Approach 

Inteligencia de negocios 
DB2 OLAP Server 
DB2 Inteliigent Miner 
DB2 Spatial Extender 
DB2 Warehouse Manager 
QMF para OS/390 

herramientas para el negocio electrónico (E-Business) 
DB2 Net Search Extender 
DB2XML Extender 
Net.Data 

DB2 para Websphere 

Integración de datos 
DB2 DataJoiner 
DataLinks 

Data Replication Services 
DB2 Connect 


Gestión de contenidos 
Content Manager 
Content Manager VideoCharger 

Herramientas de gestión de bases de datos 
DB2 Control Center 
DB2 Admin Tools para OS/390 
DB2 Buffer Pool Tool 
DB2 Estimator para OS/390 
DB2 Performance Monitor 
DB2 Visual Explain 
DB2 Query Patroller 
etc. 

Acceso móvil a datos 
DB2 EveryPlace 
DB2 Satellite Edition 


Multimedia 

DB2 ObjectRelational Extenders 
Digital Library 


FIGURA 26.1. Familia de productos DB2. 
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26.1. HERRAMIENTAS PARA EL DISEÑO DE BASES DE DATOS Y LA CONSULTA 


La mayor parte del diseño de base de datos y herra¬ 
mientas CASE se puede utilizar para diseñar una base 
de datos DB2. En particular, las herramientas de mode¬ 
lado de datos líderes tales como ERWin y Rational Rose 
permiten al diseñador generar sintaxis del LDD espe¬ 
cífica de DB2. Por ejemplo, la herramienta UML Data 
Modeler de Rational Rose puede generar instrucciones 
create distinct type del LDD específico de DB2 para 
tipos definidos por el usuario y utilizarlos posterior¬ 
mente en definiciones de columnas. La mayor parte de 
herramientas de diseño también soportan una caracte¬ 
rística de ingeniería inversa que lee las tablas del cata¬ 
logo DB2 y construye un diseño lógico para manipula¬ 
ciones adicionales. Las herramientas pueden generar 
restricciones e índices. 

DB2 proporciona constructoras SQL para soportar 
muchas características de bases de datos lógicas, tales 
como restricciones, disparadores y recursión. De igual 
forma, DB2 soporta ciertas características de bases de 
datos físicas tales como espacios de tablas, colas de 
memoria intermedia y división mediante el uso de ins¬ 
trucciones SQL. La herramienta Control Center GUI 
para DB2 permite a los diseñadores o administradores 
emitir la instrucción LDD apropiada para estas carac¬ 


terísticas. Otra herramienta permite al administrador 
obtener un conjunto completo de instrucciones LDD 
para una base de datos incluyendo espacios de tablas, 
tablas, índices, restricciones, disparadores y funciones 
que crean una réplica exacta del esquema de la base de 
datos para verificación o réplica. 

Para el análisis de datos DB2 proporciona soporte 
OLAP mediante el servidor DB2 OLAP. El servidor 
DB2 OLAP puede crear un puesto de datos multidi- 
mensional desde una base de datos DB2 subyacente para 
su análisis. El motor OLAP del producto Essbase se uti¬ 
liza en el servidor DB2 OLAP. DB2 también soporta 
otros motores OLAP de fabricantes tales como Micro- 
strategy y Cognos. En particular, DB2 proporciona 
soporte nativo para las instrucciones cube by y rollup 
para generar cubos agregados, así como agregados jun¬ 
to a una o más jerarquías en el motor de la base de datos. 
Intelligent Miner y otros productos de minería de datos 
se pueden utilizar para análisis más profundos y com¬ 
plejos en datos DB2. 

DB2 para OS/390 tiene un conjunto muy grande de 
herramientas. QMF es una herramienta ampliamente 
utilizada para generar consultas ad hoc e integrarlas en 
aplicaciones. 


26.2. VARIACIONES Y EXTENSIONES DE SQL 


DB2 soporta un amplio conjunto de características SQL 
para varios aspectos del procesamiento de la base de 
datos. Muchas de las características y sintaxis de DB2 
han proporcionado la base de los estándares en SQL-92 
y SQL: 1999. Este apartado resalta las características rela¬ 
ciónales orientadas a objetos en DB2 UDB versión 7. El 
lector puede encontrar referencias para completar la des¬ 
cripción del soporte para SQL de DB2 de IBM, así como 
extensiones al soporte XML en las notas bibliográficas. 

26.2.1. Soporte para tipos de datos 

DB2 soporta tipos de datos definidos por el usuario. Los 
usuarios pueden definir tipos de datos distintos o estruc¬ 
turados. Los tipos de datos distintos se basan en los tipos 
de datos incorporados en DB2. Sin embargo, los usua¬ 
rios pueden definir semánticas adicionales o alternati¬ 
vas para estos nuevos tipos. Por ejemplo, el usuario pue¬ 
de definir un tipo de datos distinto denominado EURO 
como 

create distinct type EURO as decimal(9,2). 

Por consiguiente, el usuario puede crear un campo (por 
ejemplo, PRECIO) en una tabla cuyo tipo sea EURO. 


Las consultas pueden utilizar el campo con este tipo en 
los predicados como en el siguiente ejemplo: 

select Producto 
from Ventas_Europa 
where Precio > EURO(IOOO) 

Los tipos de datos estructurados son objetos com¬ 
plejos que normalmente se componen de dos o más atri¬ 
butos. El siguiente código declara un tipo de datos 
estructurado denominado t_departmento: 

create type t_departmento as 
(nombredept varchar(32), 
directordept varchar(32), 
número integer) 
mode db2sql 

Los tipos estructurados se pueden utilizar para definir 
tablas con tipos. 

create table dept of t_departmento 

Con el LDD un diseñador de sistema puede crear una 
jerarquía de tipos y tablas en la jerarquía que puede here¬ 
dar métodos específicos y privilegios. Los tipos estruc¬ 
turados también se pueden utilizar para definir atribu¬ 
tos anidados dentro de una columna o tabla. 
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26.2.2. Funciones y métodos definidos 
por el usuario 

Otra característica importante es que los usuarios pue¬ 
den definir sus propias funciones y métodos. Estas fun¬ 
ciones se pueden posteriormente incluir en instruccio¬ 
nes y consultas SQL. Las funciones pueden generar 
escalares (único atributo) o tablas (fila multiatributo) 
como resultado. Los usuarios pueden registrar funcio¬ 
nes (escalares o de tablas) mediante el uso de la ins¬ 
trucción create function. Pueden escribir las funciones 
en lenguajes de programación comunes tales como C y 
Java o lenguajes de guiones tales como Rexx y Perl. Las 
funciones definidas por el usuario (LDU) pueden ope¬ 
rar en los modos separado (fenced) y compartido ( unfen- 
ced). En el modo separado las funciones se ejecutan 
mediante una hebra separada en su propio espacio de 
dirección. En el modo compartido se permite al agente 
de procesamiento de la base de datos ejecutar la fun¬ 
ción en el espacio de direcciones del servidor. Las LDU 
pueden definir un área de trabajo donde pueden mante¬ 
ner variables locales y estáticas en invocaciones dife¬ 
rentes. 

Otra característica son los métodos asociados con los 
objetos, los cuales definen el comportamiento de los obje¬ 
tos. Los métodos están asociados con tipos de datos 
estructurados particulares y se registran mediante el uso 
de la instrucción create method. 

26.2.3. Objetos de gran tamaño 

Las nuevas aplicaciones de las bases de datos requie¬ 
ren la manipulación de texto, imágenes, vídeo y otros 
tipos de datos típicos que son bastante grandes. DB2 
soporta estos requisitos proporcionando tres tipos de 
objetos de gran tamaño (LOB, Large Object) distintos. 
Cada LOB puede ser de hasta 2 gigabytes de tamaño. 
Los objetos de gran tamaño en DB2 son (1) objetos en 
binario de gran tamaño (Binary Large Objetes, BLOBs), 
(2) objetos de caracteres de gran tamaño de un único 
byte (Character Large Objects, CLOBs) y (3) objetos 


de caracteres de gran tamaño de dos bytes (Double Byte 
Character Large Objects, DBCLOBs). DB2 organiza 
estos LOBs como objetos separados, con cada fila en la 
tabla manteniendo punteros a sus LOBs correspon¬ 
dientes. Los usuarios pueden registrar UDLs que mani¬ 
pulen estos LOBs según los requisitos de la aplicación. 

26.2.4. Soporte para XML 

DB2 integra el soporte para XML en el servidor median¬ 
te el uso de XML extendido. XML extendido puede 
extraer elementos y atributos XML en columnas de datos 
relaciónales y mejorar SQL y el poder de indexación de 
DB2. De forma alternativa también puede almacenar y 
recuperar documentos XML como una única columna 
en una tabla. Puede indexar y proporcionar capacidades 
de búsqueda orientada a texto en esta columna XML. El 
extensor proporciona una serie de funciones incorpora¬ 
das y APIs para la composición, inserción, actualización 
y búsqueda en documentos XML. Es probable que se 
integren pronto nuevas características tales como la expo¬ 
sición de los datos DB2 como servicio Web mediante el 
protocolo SOAP y soporte de consultas XML. 

26.2.5. Extensiones de índices y restricciones 

Una característica reciente de DB2 proporciona un cons¬ 
tructor create Índex extensión que ayuda a crear índi¬ 
ces sobre atributos con tipos de datos estructurados 
mediante la generación de claves a partir de los tipos de 
datos estructurados. Por ejemplo, un usuario puede cre¬ 
ar un índice en un atributo cuyo tipo es t_departamen- 
to (definido en la sección 26.2.1) mediante la genera¬ 
ción de claves con el nombre departamento. El extensor 
espacial de DB2 utiliza el método de extensión de índi¬ 
ce para crear índices sobre los datos espaciales. DB2 
también proporciona un rico conjunto de característi¬ 
cas de verificación de restricciones para imponer la 
semántica de los objetos tales como unicidad, validez 
y herencia. 


26.3. ALMACENAMIENTO E INDEXACIÓN 


IBM DB2 proporciona una serie de características para 
el almacenamiento e indexación de datos. 

26.3.1. Arquitectura de almacenamiento 

DB2 proporciona abstracciones de almacenamiento para 
gestionar tablas de base de datos lógicas en entornos 
multinodo (paralelo) y multidisco. Se pueden definir 
grupos de nodos para soportar la división de la tabla en 
conjuntos especificados de nodos en un sistema multi¬ 
nodo. Esto permite flexibilidad al asignar particiones de 


tabla a nodos diferentes en un sistema. Por ejemplo, las 
tablas de gran tamaño se pueden dividir entre todos los 
nodos en un sistema mientras que las tablas pequeñas 
pueden residir en un único nodo. Las tablas se dividen 
por asociación entre los nodos en el grupo de nodos uti¬ 
lizando un subconjunto de sus atributos (clave de divi¬ 
sión). 

Dentro de un nodo, DB2 utiliza espacios de tablas 
para reorganizar la tabla. Un espacio de tablas consiste 
en uno o más contenedores que son referencias a direc¬ 
torios, dispositivos o archivos. Un espacio de tablas pue- 
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de contener cero o más objetos de base de datos tales 
como tablas, índices o LOBs. La Figura 26.2 ilustra 
estos conceptos. En esta figura se definen dos espacios 
de tablas para un grupo de nodos. Al espacio de tablas 
RECHUMANOS se asignan cuatro contenedores mien¬ 
tras que el espacio de tablas PLAN tiene solamente un 
contenedor. Las tablas EMPLEADO y DEPARTA¬ 
MENTO están en el espacio de tablas RECHUMANOS 
mientras que la tabla PROYECTO está en el espacio de 
tablas PLAN. La distribución de datos asigna fragmentos 
(extensiones) de las tablas EMPLEADO y DEPARTA¬ 
MENTO a los contenedores del espacio de tablas 
RECHUMANOS. DB2 permite al administrador crear 
tanto espacios de tablas gestionados por el sistema como 
por el SGBD. Los espacios de tablas gestionados por el 
sistema (System-managed spaces, SMSs) son directo¬ 
rios o sistemas de archivo que mantiene el sistema ope¬ 
rativo subyacente. En un SMS, DB2 crea objetos archi¬ 
vo en los directorios y asigna datos a cada uno de los 
archivos. Los espacios de tablas gestionados por el 
SGBD (Data Managed Spaces, DMSs) son dispositivos 
en bruto o archivos preasignados que son controlados 
por DB2. El tamaño de estos contenedores nunca pue¬ 
de crecer o disminuir. DB2 crea mapas de asignación y 


gestiona el espacio de tablas DMS. En ambos casos la 
unidad de espacio de almacenamiento es una extensión 
de páginas. El administrador puede elegir el tamaño de 
la extensión para un espacio de tabla. DB2 soporta la 
distribución en distintos contenedores. Por ejemplo, 
cuando se insertan los datos en una tabla recientemen¬ 
te creada, DB2 asigna la primera extensión a un conte¬ 
nedor. Una vez que la extensión está llena asigna los 
siguientes datos al siguiente contenedor por tumos rota¬ 
torios. La distribución proporciona dos ventajas signi¬ 
ficativas: E/S paralela y balance de carga. DB2 también 
soporta la preextracción y escrituras asincronas median¬ 
te el uso de hebras separadas. El componente de ges¬ 
tión de datos de DB2 desencadena la preextracción de 
páginas de datos y de índices según los patrones de acce¬ 
so de las consultas. Por ejemplo, una exploración de una 
tabla siempre desencadena la preextracción de páginas 
de datos. La exploración del índice puede desencade¬ 
nar la preextracción de páginas de índices así como las 
páginas de datos si se está accediendo de una forma 
agrupada. El número de preextracciones concurrentes 
así como el tamaño de la preextracción son parámetros 
configurables que se necesitan iniciar según el número 
de discos o contenedores en el espacio de tablas. 


Nodegroup MisDepts 



Contenedores 


FIGURA 26.2. Espacios de tablas y contenedores en DB2. 
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26.3.2. Tablas, registros e índices 

DB2 organiza los datos relaciónales como registros en 
las páginas. La Figura 26.3 muestra la vista lógica de 
una tabla y un índice asociado. La tabla consiste en un 
conjunto de páginas. Cada página consiste en un con¬ 
junto de registros (tanto registros de datos del usuario 
como registros especiales del sistema). La página cero 
de la tabla contiene registros del sistema especiales sobre 
la tabla y su estado. DB2 utiliza un registro del mapa 
de espacio denominado registro de control de espacio 
libre (Free Space Control Record, FSCR) para encon¬ 
trar el espacio libre en la tabla. El registro FSCR nor¬ 
malmente contiene un mapa de espacio de 500 páginas. 
Una entrada FSCR consiste en unos pocos bits que pro¬ 
porcionan una indicación aproximada del porcentaje de 
espacio libre en la página; por ejemplo, con dos bits, el 
patrón de bits 11 indicaría que la mayor parte de la pági¬ 
na puede estar libre mientras que 01 indicaría que alre¬ 
dedor del 25 por ciento del espacio está libre. Para redu¬ 
cir el coste de actualización, las entradas no siempre se 
actualizan con el uso del espacio real, por lo que el códi¬ 
go de inserción o actualización debe validar las entra¬ 
das FSCR realizando una verificación física del espa¬ 
cio disponible en una página. 

Los índices se organizan como páginas que contie¬ 
nen registros índice y punteros a páginas hijas y herma¬ 
nas. DB2 proporciona soporte para los mecanismos de 
índices de árbol B + . El índice de árbol B + contiene pági¬ 
nas intemas y páginas hoja. Los índices tienen punteros 
bidimensionales en el nivel hoja para soportar explora¬ 
ciones hacia delante y atrás. Las páginas hoja contienen 
entradas de índice que apuntan a los registros de la tabla. 
Cada registro de una tabla tiene un identificador de regis¬ 
tro único (Register ID, RID) construido a partir de su 
identificador de página y de ranura en la página (la estruc¬ 
tura de páginas con ranuras se describe en breve). Se 
puede definir un índice como los índices de agrupación 
de la tabla. Si se define este índice, los registros de datos 


se mantienen en un orden de agrupamiento orientado a 
la página según las claves del índice. 

Los índices DB2 pueden almacenar columnas extra 
junto con los identificadores de registro en el nivel de 
las hojas de los índices. Por ejemplo, 

create unique índex II on TI (Cl) inelude (C2) 

especifica que C2 se va a incluir como una columna extra 
en un índice sobre la columna Cl. Las columnas inclui¬ 
das permiten a DB2 utilizar las técnicas de procesamiento 
de la consulta «sólo con el índice» (evitando la lectura 
del registro real) para consultas que utilizan las colum¬ 
nas incluidas, lo que no sería posible en otro caso (el pro¬ 
cesamiento de la consulta sólo con el índice se describi¬ 
rá con más detalle en breve). Se pueden utilizar directrices 
adicionales tales como MINPCUSED y PCTLREE para 
controlar la unión de páginas de índices y su asignación 
de espacio inicial durante la carga masiva. 

La Ligura 26.4 muestra el formato de datos típico en 
DB2. Cada página de datos contiene una cabecera y un 
directorio de ranuras. El directorio de ranuras es un array 
de 255 entradas que apuntan a los desplazamientos de 
los registros en la página. La figura muestra que el núme¬ 
ro de página 473 contiene el registro cero en el despla¬ 
zamiento 3.800 y el registro 2 en el desplazamiento 
3.400. La página 1056 contiene un registro 1 en el des¬ 
plazamiento 3.700, que es realmente un puntero hacia 
delante al registro <473,2>. Por ello el registro <473, 2 
> es un registro de desbordamiento que fue creado por 
una operación de actualización del registro < 1056, 1 > 
original. DB2 soporta distintos tamaños de página tales 
como 4 KB, 8 KB, 16 KB y 32 KB. Sin embargo, cada 
página puede contener solamente 255 registros de usua¬ 
rio. Los tamaños de página mayores son útiles en apli¬ 
caciones tales como almacén de datos donde la tabla 
contiene muchas columnas. Los tamaños de página 
menores son útiles para datos operacionales con fre¬ 
cuentes actualizaciones. 


Vista lógica de la página 


Vista lógica del índice 



FIGURA 26.3. Vista lógica de las tablas e índices en DB2. 
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Página 473 


Espacio libre 
(se puede usar 
sin reorganizar 
la página*) 

Espacio libre 
incorporado 
(se puede usar 
después de 

reorganizar la página*) 


Cabecera de página 

3.800 -1 

3.400 

<- 


\ 



\ Registro 2 


Registro 0 


Núm. página Núm. ranura 

1056 1 


Página 1056 


3 bytes 1 byte 



Cabecera de página ; 

3.800 

3.700 

- - 

473,2 



Registro 0 


• establecido en la creación del espacio de tablas 

*Excepción: no se puede usar ningún 
espacio reservado por un borrado 
no comprometido 

FIGURA 26.4. Diseño de las páginas de datos y de los registros en DB2. 


26.4. PROCESAMIENTO Y OPTIMIZACIÓN DE CONSULTAS 


El compilador de consultas de DB2 transforma las con¬ 
sultas en un árbol de operaciones. DB2 utiliza enton¬ 
ces el árbol de operadores de la consulta en tiempo de 
ejecución para el procesamiento. DB2 soporta un rico 
conjunto de operadores de consulta que permiten con¬ 
siderar mejores estrategias de procesamiento y pro¬ 
porcionan flexibilidad en la ejecución de consultas com¬ 
plejas. 

Las Figuras 26.5 y 26.6 muestran una consulta y su 
plan de consulta asociado. Se trata de una consulta com¬ 
pleja representativa (consulta 5) de la prueba TPC-H y 
contiene varias reuniones y agregaciones. El plan de 
consulta en este ejemplo es bastante simple, puesto que 
solamente se definen pocos índices y no están dispo¬ 
nibles para esta consulta estructuras auxiliares como 
las vistas materializadas. DB2 proporciona varias carac¬ 
terísticas de explicación del plan incluyendo una poten¬ 
te característica visual en el centro de control que pue¬ 
de ayudar a los usuarios a comprender los detalles del 
plan de ejecución de la consulta. El plan de consulta 
en la figura está basado en la explicación visual de la 
consulta. La explicación visual permite al usuario com¬ 
prender los costes y otras propiedades relevantes de las 
distintas operaciones de un plan de consulta. 

DB2 transforma todas las consultas e instrucciones 
SQL, sin importar lo complejas que sean, en un árbol 
de consulta. La base u operadores hoja del árbol de 
consulta manipulan los registros en tablas de base de 
datos. Estas operaciones también se denominan méto¬ 
dos de acceso. Las operaciones intermedias del árbol 
incluyen operaciones del álgebra relacional tales como 
reuniones, operaciones de conjuntos y agregaciones. 
La raíz del árbol produce los resultados de la consul¬ 
ta o instrucción SQL. 


26.4.1. Métodos de acceso 

DB2 soporta un conjunto detallado de métodos de acce¬ 
so sobre tablas relaciónales, incluyendo. 

• Exploración de tabla. Con este método, el más 
básico, se accede a todos los registros en la tabla 
página por página. 

• Exploración de índice. DB2 utiliza un índice para 
seleccionar los registros específicos que satisfacen 
la consulta. Accede a los registros utilizando los 
RIDs en el índice. DB2 detecta las posibilidades 
de la preextracción de las páginas de datos cuan¬ 
do observa un patrón de acceso secuencial. 

• Sólo con el índice. Este tipo de exploración se uti¬ 
liza cuando el índice contiene todos los atributos 
que requiere la consulta. Por ello es suficiente una 
exploración de las entradas de índice y no hay 
necesidad de extraer los registros. La técnica sólo 
con el índice es normalmente una buena elección 
desde el punto de vista del rendimiento. 

• Lista de preextracción. Este método de acceso es 
una buena elección para una exploración de índi¬ 
ces no agrupada con un número significativo de 
RIDs. DB2 recoge los RIDs de los registros rele¬ 
vantes utilizando una exploración de índices, 
entonces ordena los RIDs por el número de pági¬ 
na y finalmente realiza una extracción de los regis¬ 
tros de forma ordenada desde las páginas de datos. 
El acceso ordenado cambia el patrón E/S de alea¬ 
torio a secuencial y también ofrece posibilidades 
de preextracción. 

• Conjunción de índices. DB2 utiliza este método 
cuando determina que se puede utilizar más de un 
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-'TPCD Local Supplier Volume Query (Q5)'; 
select N_NAME, 

sum(L_EXTENDEDPRICE*(1-L_DISCOUNT)) as REVENUE 
from TPCD.CUSTOMER, TPCD.ORDERS, TPCD.LINEITEM, 
TPCD.SUPPLIER, TPCD.NATION, TPCD.REGION 
where C_CUSTKEY = O.CUSTKEY 
and 0_0RDERKEY = L_ORDERKEY 
and L_SUPPKEY = S_SUPPKEY 
and C_NATIONKEY = S_NATIONKEY 
and S_NATIONKEY = N_NATIONKEY 
and N_REGIONKEY = R_REGIONKEY 
and R_NAME = 'MIDDLE EAST' 
and 0_ORDERDATE >= date('1995-01-01') 
and 0_ORDERDATE < date('1995-01-01')+ 1 year 
group by N_NAME 
order by REVENUE DESC; 


FIGURA 26.5. Consulta SQL 


índice para restringir el número de registros satis¬ 
factorios en una tabla base. Procesa el índice más 
selectivo para generar una lista de RIDs. Entonces 
procesa el siguiente índice selectivo para devolver 
los RIDs que encuentra. Un RID requiere más pro¬ 
cesamiento solamente si está presente en la inter¬ 
sección (operación AND) de los resultados de la 
exploración del índice. El resultado de una opera¬ 
ción AND del índice es una pequeña lista del RIDs 
que se utilizan para extraer los registros corres¬ 
pondientes desde la tabla base. 


• Disyunción de índices. Esta estrategia es una bue¬ 
na elección si se pueden utilizar dos o más índices 
para satisfacer los predicados de la consulta que 
se combinan utilizando la operación OR. DB2 eli¬ 
mina los RIDs duplicados realizando una ordena¬ 
ción y entonces extrae el conjunto de registros 
resultante. 

DB2 normalmente envía todos los predicados de 
selección y proyección de una consulta a los métodos 
de acceso. Además DB2 envía ciertas operaciones tales 
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FIGURA 26.6. Plan de consulta DB2 (explicación gráfica). 
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como la ordenación y la agregación, siempre que es 
posible, con el fin de reducir el coste. 

26.4.2. Operaciones de reunión, agregación 
y de conjuntos 

DB2 soporta una serie de técnicas para las operaciones 
de reunión, agregación y de conjuntos. Para la reunión 
DB2 puede elegir entre técnicas de bucles anidados, 
ordenación-mezcla y de asociación. Para describir las 
operaciones binarias de reuniones y de conjuntos se uti¬ 
lizará la notación de las tablas externas e intemas para 
distinguir los dos flujos de entrada. La técnica de bucles 
anidados es útil si la tabla intema es muy pequeña o se 
puede acceder utilizando un índice sobre un predicado 
de reunión. Las técnicas de reunión de ordenación-mez¬ 
cla y reunión por asociación son útiles para reuniones 
que involucran tablas internas y externas grandes. DB2 
implementa las operaciones de conjuntos mediante el 
uso de técnicas de ordenación y mezcla. La técnica de 
mezcla elimina los duplicados en el caso de la unión 
mientras que los no duplicados se eliminan en el caso 
de intersección. DB2 también soporta operaciones de 
reunión externa de todas las clases. 

DB2 procesa las operaciones de agregación en modo 
impaciente o de envío siempre que sea posible. Por 
ejemplo, puede realizar la agregación mientras que orde¬ 
na la entrada de la agregación en el gmpo por colum¬ 
nas. Los algoritmos de reunión y agregación aprove¬ 
chan el procesamiento superescalar en CPUs modernas 
utilizando técnicas orientadas a bloques y conscientes 
de la caché de memoria. 

26.4.3. Soporte para el procesamiento de SQL 
complejo 

Uno de los aspectos más importantes de DB2 es que uti¬ 
liza la infraestructura de procesamiento de la consulta 
de forma extensible para soportar operaciones SQL 
complejas. Las operaciones SQL complejas incluyen 
soporte para subconsultas profundamente anidadas y 
correlacionadas, así como restricciones, integridad refe- 
rencial y disparadores. Las restricciones y comproba¬ 
ciones de integridad se construyen como operaciones 
del árbol de consulta a partir de las instrucciones SQL 
de inserción, borrado o actualización. Mediante la eje¬ 
cución de la mayoría de las acciones de verificación de 
restricciones y desencadenamiento como parte del plan 
de consulta DB2 puede proporcionar una mejor efi¬ 
ciencia y dimensionabilidad. DB2 también soporta el 
mantenimiento de vistas materializadas mediante el uso 
de disparadores incorporados. 

26.4.4. Procesamiento de consultas 
en multiprocesadores 

DB2 extiende el conjunto base de operaciones de con¬ 
sulta con primitivas de intercambio de datos y control 


para soportar los modos SMP, MPP y SMP por agrupa¬ 
ciones del procesamiento de consultas. DB2 utiliza una 
abstracción tabla-cola para el intercambio de datos entre 
hebras sobre distintos nodos o sobre el mismo nodo. La 
tabla-cola es una memoria intermedia que redirige los 
datos a receptores apropiados mediante el uso de méto¬ 
dos de difusión, uno a uno o multidifusión dirigida. Las 
operaciones de control crean hebras y coordinan la ope¬ 
ración de distintos procesos y hebras. 

En todos estos modos DB2 emplea un proceso coor¬ 
dinador para controlar las operaciones de colas y la reu¬ 
nión del resultado final. Los procesos de coordinación 
también pueden ejecutar algunas acciones globales de 
procesamiento de la base de datos si es necesario. Un 
ejemplo es la operación de agregación global para com¬ 
binar los resultados de agregación local. Los subagen¬ 
tes o hebras esclavos ejecutan las operaciones base en 
uno o más modos. En el modo SMP los subagentes uti¬ 
lizan memoria compartida para sincronizarse entre sí 
cuando comparten datos. En un MPP, los mecanismos 
de tabla-cola proporcionan memoria intermedia y con¬ 
trol de flujo para la sincronización entre distintos nodos 
durante la ejecución. 

26.4.5. Optimización de consultas 

El optimizador de consultas de DB2 utiliza una repre¬ 
sentación interna de la consulta, denominada Query 
Graph Model (QGM, modelo de grafos de consultas) 
con el fin de ejecutar transformaciones y optimizacio¬ 
nes. Después de analizar la instrucción SQL, DB2 eje¬ 
cuta transformaciones semánticas sobre QGM para hacer 
cumplir las restricciones, integridad referencial y los 
disparadores. El resultado de estas transformaciones es 
un QGM mejorado. Seguidamente DB2 intenta ejecu¬ 
tar transformaciones de reescritura de la consulta que 
se consideran beneficiosas en la mayoría de las consul¬ 
tas. Se activan las reglas de reescritura, si son aplica¬ 
bles, para ejecutar las transformaciones requeridas. Los 
ejemplos de transformaciones de reescritura incluyen 
(1) descorrelación de subconsultas correlacionadas, (2) 
transformación de subconsultas en reuniones donde sea 
posible, (3) trasladar las operaciones group by bajo las 
reuniones si es aplicable y (4) reescritura de consultas 
para hacer uso de las vistas materializadas disponibles 
o «tablas resumen» (vistas materializadas utilizando la 
agregación). 

El optimizador de consultas utiliza QGM mejorado 
y transformado como su entrada para la optimización. 
El optimizador se basa en el coste y utiliza un entorno 
extensible, controlado por reglas. Se puede configurar 
el optimizador para operar a distintos niveles de com¬ 
plejidad. En el nivel más alto utiliza un algoritmo de 
programación dinámica para considerar todas las opcio¬ 
nes del plan de consulta y elige el plan de coste óptimo. 
En un nivel intermedio el optimizador no considera cier¬ 
tos planes o métodos de acceso (por ejemplo, indexa- 
ción) así como algunas reglas de reescritura. En el nivel 
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inferior de complejidad el optimizador utiliza una heu¬ 
rística impaciente simple para elegir un buen, aunque 
no necesariamente óptimo, plan de consulta. El opti¬ 
mizador utiliza modelos detallados de las operaciones 
de procesamiento de la consulta (teniendo en cuenta 
detalles tales como tamaño de la memoria y preextrac¬ 
ción) para obtener estimaciones adecuadas de los cos¬ 
tes de E/S y CPU. Depende de la estadística de los datos 
para estimar la cardinalidad y selectividades de las ope¬ 
raciones. 

DB2 permite a un usuario generar histogramas de dis¬ 
tribuciones en el nivel de las columnas y combinaciones 
de columnas mediante el uso de la utilidad runstats. Los 
histogramas contienen información sobre las aparicio¬ 
nes del valor más frecuente, así como sobre las distribu¬ 
ciones de frecuencia basadas en los cuantiles de los atri¬ 
butos. El optimizador de consultas usa estas estadísticas. 
El optimizador genera un plan de consulta interno que 
considera el mejor plan de consulta y entonces convier¬ 
te el plan de consulta en hebras de operadores y estruc¬ 
turas de datos asociados de la consulta para su ejecución 
mediante el motor de procesamiento de consultas. 


Considérese una actualización de la forma «Aumen¬ 
tar en un 10 por ciento el sueldo de los empleados que 
ganen menos que 25.000 euros». En una versión ante¬ 
rior de System R el optimizador elegía el índice del suel¬ 
do para el acceso y procesaba los datos de menor a 
mayor (0 a 25.000). La inserción de un nuevo valor 
(mayor) para el sueldo significaba que el registro actua¬ 
lizado se revisa de nuevo a no ser que el valor del suel¬ 
do fuera mayor que 25.000. La causa de la revisión es 
el uso del índice del sueldo para el acceso en orden 
menor a mayor. Se revisaba el registro y el sueldo se 
aumentaba un 10 por ciento repetidamente hasta que su 
valor excedía a 25.000. Este error ocurrió el día de Hallo- 
ween, por lo que los miembros del proyecto System R 
lo denominaron al error «problema Halloween». 

DB2 soluciona el problema Halloween reconocien¬ 
do esta situación en el compilador de la consulta. El 
optimizador genera un plan de consulta que primero 
materializa los RIDs de las filas implicadas antes de pro¬ 
cesar las actualizaciones. Cada registro implicado se 
actualiza solamente una vez, como tenía intención la 
instrucción de actualización. 


26.5. CONTROL DE CONCURRENCIA Y RECUPERACIÓN 


DB2 soporta técnicas de control de concurrencias que 
proporcionan un muy alto nivel de concurrencia, aco¬ 
pladas con un mecanismo de recuperación avanzado 
que soporta una serie de características. 

26.5.1. Concurrencia y aislamiento 

DB2 soporta una serie de modos de control de concu¬ 
rrencia y aislamiento. Para el aislamiento DB2 soporta 
los modos lectura repetible (Repeatable Read, RR), esta¬ 
bilidad en lectura (Read Stability, RS), estabilidad del 
cursor (Cursor Stability, CS) y lectura no comprometi¬ 
da (Un-committed Read, UR). 

La definición de lectura repetible en DB2 difiere de 
la del Apartado 16.8 y corresponde íntimamente con el 
nivel secuenciable descrito allí. Específicamente, RR 
en DB2 asegura que la exploración del rango encontra¬ 
rá el mismo conjunto de tupias si se repiten. Si todas las 
transacciones siguen el protocolo RR entonces la pla¬ 
nificación resultante será secuenciable. Los modos CS 
y UR son como se describen en el Apartado 16.8. 

El modo de aislamiento RS bloquea solamente las 
filas que recupera una aplicación en una unidad de tra¬ 
bajo. En una exploración posterior la aplicación tiene 
garantizado ver todas estas filas (como RR) pero podría 
no ver nuevas filas que debería ver. Sin embargo, esto 
podría ser un compromiso aceptable para algunas apli¬ 
caciones con respecto al aislamiento RR estricto. Nor¬ 
malmente el nivel de aislamiento predeterminado es CS. 
Las aplicaciones pueden elegir el nivel de aislamiento 


con el que se quieren ejecutar. También, la mayoría de 
las aplicaciones comerciales disponibles soportan los 
distintos niveles de aislamiento y los usuarios pueden 
elegir la versión correcta de la aplicación para sus requi¬ 
sitos. 

Los distintos modos de aislamiento se implementan 
mediante el uso de bloqueos. DB2 soporta bloqueos en 
el nivel de registros y de tablas. Mantiene una estruc¬ 
tura de datos de bloqueo de tablas separado del resto de 
información de bloqueo. DB2 dimensiona el bloqueo 
en el nivel de registros al de tablas si el espacio dispo¬ 
nible para posteriores bloqueos en la tabla de bloqueos 
se hace pequeño. DB2 implementa un bloqueo estricto 
de dos fases para todas las transacciones de actualiza¬ 
ción. Mantiene bloqueos de escritura y actualización 
hasta el momento del compromiso o retroceso. 

DB2 soporta una serie de modos de bloqueo con el 
fin de maximizar la concurrencia. La Figura 26.7 mues¬ 
tra los distintos modos de bloqueo y proporciona una 
breve descripción del propósito de cada modo de blo¬ 
queo. Abajo se muestran brevemente algunos de los 
modos de bloqueo; véanse las referencias bibliográfi¬ 
cas para mayor información sobre los modos de blo¬ 
queo. Los modos de bloqueo incluyen bloqueos inten¬ 
cionales en un nivel de tabla para proporcionar bloqueo 
de granularidad múltiple. DB2 también implementa el 
bloqueo de la clave siguiente para las inserciones y 
borrados que afecten a las exploraciones de índices del 
nivel de aislamiento RR para eliminar el problema de 
la lectura fantasma. Véanse las referencias bibliográfi- 
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Modo de bloqueo 

Objetos 

Interpretación 

IN (¡ntent none, sin intención) 

Espacios de tablas, tablas 

Lectura sin bloqueos de filas 

IS (¡ntent share, intentar compartir) 

Espacios de tablas, tablas 

Lectura con bloqueos de filas 

NS (next key share, siguiente clave 
compartido) 

Filas 

Bloqueos de lectura para los niveles 
de aislamiento RS o CS 

S (share, compartido) 

Filas, tablas 

Bloqueo de lectura 

IX (¡ntent exclusive, intencional exclu¬ 
sivo) 

Espacios de tablas, tablas 

Intención de actualizar filas 

SIX (share with ¡ntent Exclusive, com¬ 
partido intencional exclusivo) 

Tablas 

Sin bloqueos de lectura en las filas 
pero con bloqueos X en las filas 
actualizadas 

U (Update, actualización) 

Filas, tablas 

Bloqueo de actualización pero permi¬ 
tiendo leer a otros 

NX (next key exclusive, siguiente 
clave exclusivo) 

Filas 

Bloqueo de la siguiente clave para 
inserciones y borrados para prevenir 
las lecturas fantasma durante las 
exploraciones de índice RR 

X (exclusive, exclusivo) 

Filas, tablas 

Sólo se permiten lectores no compro¬ 
metidos 

Z (superexclusive, superexclusivo) 

Espacios de tablas, tablas 

Acceso completo exclusivo 


FIGURA 26.7. Modos de bloqueo de DB2. 


cas para mayores detalles (en el Apartado 16.9 se des¬ 
cribe una forma sencilla de bloqueo de la siguiente cla¬ 
ve que elimina el problema fantasma). 

La transacción puede establecer la granularidad del 
bloqueo en el nivel de tabla mediante el uso de una ins¬ 
trucción de bloqueo de tabla (una extensión SQL). Esto 
es útil para aplicaciones que conocen que su nivel dese¬ 
ado de aislamiento está en el nivel de tabla. También 
DB2 elige las granularidades de bloqueo apropiadas 
cuando se ejecutan utilidades tales como reorganización 
de la base de datos y bloqueo. Las versiones sin cone¬ 
xión de estas utilidades normalmente bloquean la tabla 
en modo exclusivo. Las versiones en conexión de las 
utilidades permiten que otras transacciones se ejecuten 
concurrentemente adquiriendo bloqueos de filas. 

En cada base de datos se ejecuta un agente de detec¬ 
ción de interbloqueos que periódicamente verifica los 
interbloqueos entre las transacciones. El intervalo para 
la detección de interbloqueos es un parámetro configu¬ 
rable. En caso de interbloqueo, el agente elige una víc¬ 
tima y la finaliza. La víctima produce un código de error 
SQL, indicando que la causa del fallo fue un interblo¬ 
queo. 

26.5.2. Compromiso y retroceso 

Las aplicaciones pueden comprometerse o retroceder- 
se mediante el uso de las instrucciones explícitas com- 
mit y rollback. Las aplicaciones también pueden emi¬ 
tir instrucciones begin transaction y end transaction 
para controlar el ámbito de las transacciones. No se 
soportan las transacciones anidadas. Normalmente DB2 
libera todos los bloqueos que se mantienen por una tran¬ 
sacción en commit o rollback. Sin embargo, si se ha 
declarado una instrucción de cursor mediante la cláu¬ 


sula withhold entonces se mantienen algunos bloqueos 
durante los compromisos. 

26.5.3. Registro histórico y recuperación 

DB2 implementa el registro histórico y los esquemas 
de recuperación ARIES (el esquema ARIES se descri¬ 
be brevemente en el Apartado 17.9.6). Este registro his¬ 
tórico de escritura anticipada lo utiliza para enviar regis¬ 
tros desde este registro histórico al archivo de registro 
histórico persistente, antes de que las páginas de datos 
se escriban en el compromiso. DB2 soporta dos tipos 
de modos de registro: registro histórico circular y regis¬ 
tro de archivo. En el registro histórico circular, DB2 uti¬ 
liza un conjunto predefinido de archivos de registro his¬ 
tórico primario y secundario. El registro histórico 
circular es útil para la recuperación de caídas o la recu¬ 
peración de un fallo de la aplicación. En el registro his¬ 
tórico de archivo, DB2 crea nuevos archivos de regis¬ 
tro histórico y guarda los archivos de registro histórico 
viejos con el fin de liberar espacio en el sistema de archi¬ 
vos. Los registros históricos de archivo son necesarios 
para la recuperación hacia adelante de una copia de segu¬ 
ridad de archivo (se describe con más detalle más ade¬ 
lante). En ambos casos DB2 permite al usuario confi¬ 
gurar el número de archivos de registro histórico y los 
tamaños de los archivos de los registros históricos. 

En entornos con grandes actualizaciones, DB2 pue¬ 
de configurarse para utilizar compromisos en grupo 
(Apartado 24.3) con el fin de combinar escrituras de 
registro histórico de varias transacciones y ejecutarlos 
utilizando una única operación E/S. 

DB2 soporta retroceso de transacciones, recupera¬ 
ción de caídas, así como recuperaciones por instantes 
(point-in-time) o hacia adelante (roll-forward ). En el 
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caso de una recuperación tras una caída, DB2 ejecuta 
las fases de deshacer estándar de procesamiento y pro¬ 
cesamiento rehacer hasta y desde el último punto de 
revisión con el fin de recuperar el estado comprometi¬ 
do adecuado de la base de datos. Para la recuperación 
por instantes, DB2 puede restaurar la base de datos des¬ 
de una copia de seguridad y avanzar a un punto especí¬ 
fico en el tiempo utilizando los archivos históricos guar¬ 
dados. El comando de recuperación hacia adelante 


soporta tanto los niveles de bases de datos como de espa¬ 
cios de tablas. También se pueden emitir en nodos espe¬ 
cíficos sobre un sistema multinodo. 

Recientemente se ha hecho disponible un esquema 
de recuperación en paralelo para mejorar el rendimien¬ 
to en sistemas multiprocesador SMP mediante la utili¬ 
zación de muchas CPUs. DB2 ejecuta la recuperación 
coordinada a través de nodos MPP mediante un esque¬ 
ma global de puntos de revisión. 


26.6. ARQUITECTURA DEL SISTEMA 


La Figura 26.8 muestra algunos de los distintos proce¬ 
sos o hebras en un servidor DB2. Las aplicaciones 
remotas cliente se conectan al servidor de la base de 
datos a través de agentes de comunicación tales como 
db2tcpcm. Se asigna un agente a cada aplicación (agen¬ 
te coordinador en entornos MPP o SMP) denominado 
hebra dh2agent. Este agente y sus agentes subordina¬ 
dos ejecutan las tareas relacionadas con la aplicación. 
Cada base de datos tiene un conjunto de procesos o 
hebras que ejecutan tareas tales como preextracción. 


limpieza de páginas de la cola de la memoria interme¬ 
dia y detección de interbloqueos. Finalmente hay un 
conjunto de agentes en el entorno del servidor para eje¬ 
cutar tareas tales como detección de caídas, creación 
de procesos, control de recursos del sistema y servicio 
de licencia. DB2 proporciona parámetros de configu¬ 
ración para controlar el número de hebras y procesos 
en un servidor. Casi todos los tipos distintos de agen¬ 
tes se pueden controlar mediante el uso de parámetros 
de configuración. 
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FIGURA 26.8. Modelo de procesos en DB2. 
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La Figura 26.9 muestra los distintos tipos de seg¬ 
mentos de memoria en DB2. La memoria privada en los 
agentes o hebras se utiliza principalmente para varia¬ 
bles locales y estructuras de datos que son relevantes 
solamente para la actividad actual. Por ejemplo, una 
ordenación privada podría asignar memoria desde el 
montículo privado del agente. La memoria compartida 
se divide en memoria compartida del servidor, memo¬ 
ria compartida de la base de datos y memoria compar¬ 
tida de la aplicación. El nivel de la base de datos de 
memoria compartida contiene estructuras de datos úti¬ 
les tales como las colas de memoria intermedia, las lis¬ 
tas de bloqueos, las cachés de los paquetes de aplica¬ 
ción y las áreas de ordenación compartida. Las áreas de 
memoria compartida del servidor y de la aplicación se 
utilizan principalmente para estmcturas de datos comu¬ 
nes tales como parámetros de configuración del servi¬ 
dor y memorias intermedias de comunicaciones. 

DB2 soporta varias colas de memoria intermedia para 
una base de datos. Las colas de memoria intermedia se 
pueden crear mediante el uso de la instrucción create buf- 
ferpool y se puede asociar con espacios de tablas. Es útil 


disponer de varias colas de memoria intermedia por diver¬ 
sas razones, pero se deberían definir después de un cui¬ 
dadoso análisis de los requisitos de la carga de trabajo. 
DB2 también proporciona la capacidad de almacena¬ 
miento extendido para aprovechar memorias grandes 
(memorias mayores de 4 gigabytes) en sistemas que sola¬ 
mente tienen capacidad de direccionamiento de 32 bits. 
El almacenamiento extendido se utiliza como una memo¬ 
ria intermedia de copia de seguridad compartida para 
colas de memoria intermedia activas. Las páginas que se 
extraen o reemplazan de una cola de memoria interme¬ 
dia activa se escriben en el área de almacenamiento 
extendido y se pueden volver a copiar desde allí si se 
necesita. Por ello, el almacenamiento extendido puede 
ayudar a evitar E/S en grandes sistemas de memoria. 

DB2 soporta una completa lista de configuración de 
memoria y parámetros de ajuste. Esto incluye paráme¬ 
tros para todas las áreas de montículos de estructuras 
de datos grandes tales como las colas de memoria inter¬ 
media predeterminadas, el montículo de ordenación, la 
caché de paquetes, los montículos de control de la apli¬ 
cación, el área de lista de bloqueos y cosas similares. 



1...máxagentes 


FIGURA 26.9. Modelo de memoria DB2. 
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26.7. RÉPLICAS. DISTRIBUCIÓN Y DATOS EXTERNOS 


DB2 Data Propagator es un producto en la familia DB2 
que proporciona réplica de datos entre DB2 y otros sis¬ 
temas de bases de datos relaciónales tales como Oracle, 
SQL Server de, SQL Server de Sybase e Informix, y orí¬ 
genes de datos no relaciónales tales como IMS de IBM. 

Data Propagator consiste en componentes capturar 
y aplicar que se controlan mediante interfaces de admi¬ 
nistración. Los mecanismos de captura de cambios se 
basan en tablas DB2 basadas en registros históricos o 
basadas en disparadores en el caso de otros orígenes de 
datos. Esto es, para las tablas DB2 los cambios se detec¬ 
tan examinando el registro de la base de datos mientras 
que los disparadores se utilizan para detectar los cam¬ 
bios de otros orígenes de datos. Los cambios captura¬ 
dos se almacenan en áreas temporales de tablas bajo el 
control del propagador de datos DB2, que se aplican 
después a estas tablas intermedias, con cambios, a las 
tablas destino mediante el uso de instrucciones SQL 
(inserciones, actualizaciones y borrados). Las transfor¬ 
maciones basadas en SQL se pueden ejecutar sobre estas 
tablas intermedias utilizando condiciones de filtro ade¬ 
más de agregaciones. Las filas resultantes se pueden 
aplicar a una o más tablas destino. Los medios de admi¬ 
nistración controlan todas estas acciones. 


Otro miembro de la familia DB2 es el producto Data 
Joiner, que proporciona soporte a bases de datos federa¬ 
das y distribuidas. Data Joiner puede integrar tablas en 
DB2 remotas u otras bases de datos relaciónales en una 
única base de datos distribuida. Data Joiner proporcio¬ 
na un método basado en el coste para la optimización de 
consultas entre los distintos sitios de datos. Los datos no 
relaciónales también se pueden integrar en Data Joiner 
mediante el uso de envolturas para crear datos tabulares. 

DB2 soporta funciones de tabla definidas por el usua¬ 
rio que pueden permitir el acceso de orígenes de datos 
no relaciónales y externos. DB2 crea funciones de tabla 
definidas por el usuario mediante la instrucción create 
function con la cláusula returns table. Con estas caracte¬ 
rísticas DB2 puede participar en los protocolos OLE-DB. 

Finalmente DB2 proporciona soporte completo para 
procesamiento de transacciones distribuidas mediante 
el protocolo de compromiso en dos fases. DB2 puede 
actuar como el coordinador o agente para el soporte de 
transacciones distribuidas. Como coordinador, DB2 pue¬ 
de ejecutar todos los estados del protocolo de compro¬ 
miso en dos fases. Como participante, DB2 puede inte¬ 
ractuar con cualquiera de los administradores de 
transacciones distribuidas comerciales. 


26.8. HERRAMIENTAS DE ADMINISTRACIÓN DE BASES DE DATOS 


DB2 proporciona una serie de herramientas para faci¬ 
litar el uso y administración. Las herramientas creadas 
por los fabricantes han permitido la mejora del núcleo 
del conjunto de herramientas del programa. 

El centro de control DB2 es la herramienta primaria 
para el uso y administración de bases de datos DB2. El 
centro de control se ejecuta sobre muchas plataformas 
del tipo estación de trabajo. Tiene interfaces para admi¬ 
nistrar objetos de distintos tipos, tales como servidores, 
bases de datos, tablas e índices. Además contiene inter¬ 
faces orientadas en las tareas para ejecutar comandos y 
permite a los usuarios generar secuencias de comandos 
SQL. 

La Figura 26.10 es una pantalla del panel principal 
del centro de control. Muestra una lista de tablas en la 
base de datos Sample en la instancia DB2 sobre el nodo 
CranKarm. El administrador puede utilizar el menú para 
invocar un conjunto de herramientas componentes. Los 
componentes principales del centro de control son el 
centro de órdenes, el centro de guiones, diario, gestión 
de licencias, centro de alertas, supervisor del rendi¬ 
miento, explicación visual, administración de bases de 
datos remotas, gestión de almacenamiento y soporte 
para la réplica. El centro de órdenes permite a los usua¬ 
rios y administradores enviar órdenes de la base de datos 


y ejecutar instrucciones SQL. El centro de guiones per¬ 
mite a los usuarios ejecutar guiones SQL construidos 
de forma interactiva o desde un archivo. El supervisor 
del rendimiento permite al usuario supervisar varios 
eventos en el sistema de la base de datos y obtener ins¬ 
tantáneas del rendimiento. SmartGuides proporciona 
ayuda para la configuración de parámetros del sistema 
DB2. Un constructor de procedimientos almacenados 
ayuda al usuario a desarrollar e instalar estos procedi¬ 
mientos. La explicación visual da al usuario vistas grá¬ 
ficas del plan de ejecución de la consulta. Un asistente 
de índices ayuda al administrador sugiriendo índices de 
rendimiento. 

Aunque el centro de control es una interfaz integrada 
de muchas de las tareas, DB2 también proporciona acce¬ 
so directo a la mayoría de las tareas. Para los usuarios las 
herramientas tales como la característica de explicación, 
las tablas de explicación y la explicación gráfica pro¬ 
porcionan un análisis detallado de los planes de consul¬ 
ta. Los usuarios pueden utilizar el centro de control para 
modificar las estadísticas (si se peimite la modificación) 
con el fin de generar los mejores planes de consulta. 

Para los administradores, DB2 proporciona un sopor¬ 
te completo para la carga, importación, exportación, 
reorganización, redistribución y otras utilidades rela- 
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FIGURA 26.10. Centro de control DB2. 


cionadas con los datos. Además, DB2 soporta herra¬ 
mientas tales como: 

• Auditoría para el mantenimiento de la traza de 
auditoría de las acciones sobre la base de datos 

• Regulador para controlar la prioridad y tiempos de 
ejecución en distintas aplicaciones 


• Supervisor de consultas para gestionar los traba¬ 
jos de consulta en el sistema 

• Características de traza y diagnóstico para la depu¬ 
ración 

• Supervisión de eventos para seguir los recursos y 
eventos durante la ejecución del sistema. 


26.9. RESUMEN 


Este capítulo proporciona una breve sinopsis de carac¬ 
terísticas disponibles en DB2. Como resumen, DB2 es 
un servidor de bases de datos multi-plataforma, dimen- 


sionable y relacional orientado a objetos. En las notas 
bibliográficas se citan libros y guías más completos so¬ 
bre DB2. 


NOTAS BIBLIOGRÁFICAS 


Chamberlin [1996] y Chamberlin [1998] proporcio¬ 
nan una buena revisión de las características de SQL 
y programación de DB2. Los primeros libros de Date 
[1989] y Martin et al. [1989] proporcionan un buen 
repaso de las características de DB2 para OS/390. Los 
manuales de DB2 proporcionan revisiones definitivas 
de varias versiones de DB2. La mayoría de estos 
manuales están disponibles en línea en el sitio 
http://www.software.ibm.com/data/pubs. Libros recien¬ 
tes que proporcionan un entrenamiento práctico para 
el uso y administración de DB2 son Zikopoulos et al. 
[2000], Sanders [2000] y Cook et al. [1999], Linal- 
mente, Prentice Hall está publicando una serie com¬ 
pleta de libros sobre el enriquecimiento y certificación 
sobre varios aspectos de DB2. 

La investigación de IBM sobre XML incluye Shan- 
mugasundaram et al. [2000] y Carey et al. [2000]. IBM 


ha sido un participante activo en la estandarización de 
XQuery. Se puede encontrar detalles sobre la extensión 
XML de DB2 en línea en el sitio 

http://www.software.ibm.com/data/db2/exten- 

ders/xmlext. 

Para una descripción detallada de los modos de blo¬ 
queo y su uso véase DB2 Administration Guide (capí¬ 
tulo Application Considerations), que está disponible 
en línea en http://www.software.ibm.com/data/pubs. 
Mohán [1990a] y Mohán y Levine [1992] proporcio¬ 
nan descripciones detalladas del control de concurren¬ 
cia de índices en DB2. 

Las contribuciones a la investigación de IBM, algu¬ 
nas de las cuales se listan más adelante, han mejorado 
continuamente el producto DB2. Chamberlin et al. 
[1981] proporciona una historia y evaluación del pro¬ 
yecto System R, que jugó una función crucial en el desa- 
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rrollo de bases de datos relaciónales y condujo al 
desarrollo del producto DB2. El problema Halloween 
y otros aspectos de la historia de System R aparecen en 
http://www.mcjones.org/System R/SQL Reunión 
95/index.html. 

Las técnicas de procesamiento de transacciones tales 
como el registro histórico de escritura anticipada y los 
algoritmos de recuperación ARIES se describen en 


Mohán et al. [1992]. El procesamiento y optimización 
de consultas en Starbrust se describen en Haas et al. 
[1990]. El procesamiento en paralelo en DB2 Parallel 
Edition se describe en Baru et al. [1995]. El soporte de 
bases de datos activas, incluyendo las restricciones y 
los disparadores, se describen en Cochrane et al. [1996]. 
Carey et al. [1999] describe el soporte relacional orien¬ 
tado a objetos en DB2. 
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SOL SERVER DE MICROSOFT 

Sameet Agarwal, José A. Blakeley, Thomas Casey, 
Kalen Delaney, César Galindo-Legaria, Goetz Graefe 
Michael Rys, Michael Zwilling 
Microsoft 


S QL Server de Microsoft es un sistema gestor de bases de datos relaciónales que se usa 
desde en portátiles y ordenadores de sobremesa hasta en servidores corporativos, con una 
versión compatible, basada en el sistema operativo PocketPC, disponible para dispositi¬ 
vos de bolsillo, tales como PocketPCs y lectores de código de barras. SQL Server se desarro¬ 
lló originalmente en los años 80 en SyBase para sistemas UNIX y posteriormente pasado a sis¬ 
temas Windows NT para Microsoft. Desde 1994 Microsoft ha lanzado versiones de SQL Server 
desarrolladas independientemente de Sybase, que dejó de utilizar el nombre SQL Server a fina¬ 
les de los años 90. La última versión disponible es SQL Server 2000, disponible en ediciones 
personales, para desarrolladores, estándar y corporativa, y traducida a muchos lenguajes en todo 
el mundo. En este capítulo el término SQL Server se refiere a todas estas ediciones de SQL Ser- 
ver 2000. 

SQL Server proporciona servicios de réplica entre varias copias de SQL Server así como 
con otros sistemas de bases de datos. Sus Analysis Services (servicios de análisis), una parte 
integral del sistema, incluye dispositivos de procesamiento en conexión analítico (OLAP, Onli¬ 
ne Analytical Processing) y recopilación de datos. SQL Server proporciona una gran colección 
de herramientas gráficas y «asistentes» que guían a los administradores de las bases de datos 
por tareas tales como establecer copias de seguridad regulares, réplica de datos entre servido¬ 
res y ajuste del rendimiento de una base de datos. Muchos entornos de desarrollo soportan SQL 
Server, incluyendo Visual Studio de Microsoft y productos relacionados, en particular los pro¬ 
ductos y servicios .NET. 



27.1. HERRAMIENTAS PARA EL DISEÑO Y CONSULTA DE BASES DE DATOS 


SQL Server proporciona un conjunto de herramientas 
para gestionar todos los aspectos del desarrollo de SQL 
Server, consulta, ajuste, verificación y administración. 
La mayoría de estas herramientas se centran alrededor 
del Administrador corporativo de SQL Server. El admi¬ 
nistrador corporativo es un complemento accesorio de 
Microsoft Management Consolé (MMC), una herra¬ 
mienta que proporciona una interfaz común para traba¬ 
jar con varias aplicaciones del servidor en una red Win¬ 
dows. 

27.1.1. Desarrollo de bases de datos 
y herramientas visuales 

Mientras se diseña una base de datos, el administrador 
de la base de datos crea objetos de bases de datos tales 
como tablas, coulmnas, claves, índices, relaciones, res¬ 
tricciones y vistas. Para ayudar a crear estos objetos el 
Administrador corporativo de SQL Server proporciona 
acceso a herramientas visuales de bases de datos. Estas 
herramientas proporcionan tres mecanismos para ayu¬ 
dar al diseño de la base de datos: el diseñador de bases 
de datos, el diseñador de tablas y el diseñador de vis¬ 
tas. Las herramientas visuales también proporcionan 


una herramienta de consulta visual que permite al admi¬ 
nistrador de la base de datos el uso de capacidades de 
arrastrar y soltar para constmir consultas visualmente. 

El diseñador de bases de datos es una herramienta 
visual que permite al administrador de la base de datos 
crear tablas, columnas, claves, índices, relaciones y res¬ 
tricciones. Con el diseñador de bases de datos, un usua¬ 
rio puede interactuar con los objetos de la base de datos 
mediante diagramas de base de datos, los cuales mues¬ 
tran de forma gráfica la estructura de la base de datos. 
El usuario puede crear y modificar objetos que son visi¬ 
bles sobre diagramas (tablas, columnas, relaciones y 
claves) y algunos objetos que no son visibles en los dia¬ 
gramas (índices y restricciones). La Figura 27.1 mues¬ 
tra el diagrama de una base de datos abierto con el Admi¬ 
nistrador corporativo. 

27.1.2. Herramientas de consulta y ajuste 
de las bases de datos 

SQL Server proporciona herramientas para ayudar al 
proceso de desarrollo de aplicaciones. Se pueden desa¬ 
rrollar y verificar inicialmente las consultas y procedi¬ 
mientos almacenados utilizando el Analizador de con- 
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FIGURA 27.1. Diagrama que muestra las opciones del diseñador de tablas para la tabla de empleados. 


sultas de SQL Server, el cual proporciona herramientas 
básicas de consulta y ajuste de las bases de datos. Se 
pueden realizar otros análisis utilizando el Analizador 
de SQL Server. Las recomendaciones del ajuste de índi¬ 
ces vienen proporcionadas por una tercera herramien¬ 
ta, el Asistente de optimización de índices. 

27.1.2.1. Analizador de consultas de SQL 

EL Analizador de consultas de SQL proporciona una 
interfaz de usuario sencilla y gráfica para ejecutar con¬ 
sultas SQL y ver los resultados. Permite varias venta¬ 
nas de forma que pueden existir conexiones de bases de 
datos simultáneas (una o más instalaciones de SQL Ser- 
ver). Un desarrollador de consultas puede elegir tener 
resultados de consulta mostrados en una ventana de tex¬ 
to o en una rejilla. El Analizador de consultas de SQL 
proporciona una representación gráfica de showplan, 
los pasos elegidos por el optimizador para la ejecución 
de la consulta. También proporciona informes opcio¬ 
nales de los comandos reales procesados por SQL Ser- 
ver (una traza en el cliente) y el trabajo realizado por el 
cliente. El Analizador de consultas de SQL viene con 
un explorador de objetos y permite al usuario arrastrar 


y soltar objetos o nombres de tablas en la tabla. Tam¬ 
bién incluye la herramienta de depuración de Transact- 
SQL. El depurador permite a un usuario depurar paso 
a paso cualquier procedimiento almacenado, exami¬ 
nando el comportamiento de los parámetros, las varia¬ 
bles locales y las funciones del sistema mientras se eje¬ 
cutan estos pasos. 

Un administrador o desarrollador de la base de 
datos puede utilizar el Analizador de consultas de SQL 
para: 

• Analizar consultas: el Analizador de consultas de 
SQL Server puede mostrar un plan de ejecución 
gráfico o contextual para cualquier plan de con¬ 
sultas, así como mostrar estadísticas relacionadas 
con el tiempo y recursos requeridos para ejecutar 
cualquier plan. 

• Dar formato a las consultas SQL: el Analizador de 
consultas permite la sangría y su eliminación en 
las líneas de código, cambio de la caja de las pala¬ 
bras o secciones de código, comentar una única o 
varias líneas y mostrar las consultas con un códi¬ 
go de color controlado por el usuario. 
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^Analizador de consultas SQL 


Archivo Edición Consulta Herramientas Ventana Anuda 


1 íS - H í§ X % © G? Í4 10 | ® " V ► ■ tj Northwind 

T| ^ 

B 



Consulta - PC-FERNAN.Northw¡nd.FISDIA\fernan - 2 sin título* 


SELECT e.LastName, p,ProductName, sum(d.Quantity * d.UnitPrice) 
FROM [Order Details] d 
JOIN Orders o 

ON o.OrderID = d.OrderID 
JOIN Products p 

ON d.ProductID = p.ProductID 
JOIN Employees e 

[l'N e . Emp loyeeID = o. Emp loyee ID 
GROUP BY e.LastName, p.ProductName 


ii 


Consulta 1: costo de la consulta (en relación al proceso por lotes):0,00% 

Texto de la consulta:SELECT e.LastName, p.ProductName, sum(d.Quantity * d.UnitPrice) F 


SELECT 
Costo: 0% 



Stream Aggregat... 
Costo: 0% 


s—I 

Sort Hash Match/ Inne . . .Products . Produc. . . 

Costo: 0% Costo: 0% Costo: 0% 


Nested Loops/In. . Nes 
Costo: 0% 


FIGURA 27.2. Un plan de ejecución con showplan para una reunión de cuatro tablas con una agregación group by. 


• Utilizar plantillas para procedimientos almacena¬ 
dos, funciones e instrucciones SQL básicas: el Ana¬ 
lizador de consultas viene con docenas de plantillas 
predefinidas para construir instrucciones LDD, y 
los usuarios pueden definir las suyas propias. Cuan¬ 
do se ejecuta una plantilla los usuarios pueden pro¬ 
porcionar valores específicos para los nombres de 
objetos y columnas, tipos de datos y otra informa¬ 
ción específica. 

• Arrastrar nombres de objetos desde el Explorador 
de objetos a la ventana Consulta: el Analizador de 
consultas permite al desarrollador elegir la defini¬ 
ción de un objeto o, para tablas y vistas, ver plan¬ 
tillas para crear instrucciones ¡nsert, update, dele- 
te o select. 

• Definir teclas de acceso directo y opciones de la 
barra de herramientas personales: el Analizador de 
consultas permite definir teclas de acceso directo 
para una ejecución rápida de consultas comunes y 
proporciona un control completo sobre los coman¬ 
dos que están disponibles como botones en la tabla 
de herramientas y en qué posición aparecen los 
botones. 


La Figura 27.2 muestra el Analizador de consultas mos¬ 
trando el plan de ejecución gráfico para una consulta que 
involucra una reunión de cuatro tablas y una agregación. 

27.1.2.2. Analizador de SQL 

El Analizador de SQL es una utilidad gráfica que per¬ 
mite a los administradores de la base de datos supervi¬ 
sar y registrar la actividad de la misma. El Analizador 
de SQL puede mostrar toda la actividad del servidor en 
tiempo real o puede crear filtros que se centren en las 
acciones de usuarios particulares, aplicaciones o tipos 
de órdenes. El Analizador de SQL puede mostrar cual¬ 
quier instrucción SQL o procedimiento almacenado 
enviado a cualquier ejemplar de SQL Server (si los pri¬ 
vilegios de seguridad lo permiten) así como los datos 
de rendimiento que indican cuánto tiempo la consulta 
tardó en ejecutarse y cuánta CPU y E/S fue necesaria y 
el plan de ejecución que utilizó la consulta. 

El Analizador de SQL permite ahondar aún más en 
SQL Server para supervisar automáticamente toda ins¬ 
trucción ejecutada como parte de un procedimiento 
almacenado, toda operación de modificación de datos, 
todo bloqueo adquirido o liberado, o cada vez que cre- 
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ce un archivo de base de datos. Hay docenas de even¬ 
tos distintos que se pueden capturar y docenas de ele¬ 
mentos de datos que se pueden capturar para cada even¬ 
to. SQL Server realmente divide la funcionalidad de 
traza en dos componentes separados aunque conecta¬ 
dos. El Analizador de SQL está en la traza del cliente. 
Mediante el uso del Analizador de SQL un usuario pue¬ 
de elegir guardar los datos capturados a un archivo o 
una tabla, además de mostrarlos en la interfaz de usua¬ 
rio del Analizador (IU). El Analizador muestra todo 
evento que cumple el criterio del filtro mientras ocurre. 
Una vez que se han guardado los datos de la traza, el 
Analizador de SQL puede leer los datos guardados para 
mostrarlos o analizarlos. 

En el lado del servidor está la traza de SQL, que 
gestiona las colas de eventos generados por producto¬ 
res de eventos. Una hebra consumidora lee los even¬ 
tos desde las colas y los filtra antes de enviarlos al pro¬ 
ceso que las solicitó. Los eventos son la unidad 
principal de actividad en lo que se refiere a la traza, y 
un evento puede ser cualquier cosa que suceda dentro 
de SQL Server o entre SQL Server y un cliente. Por 
ejemplo, la creación o eliminación de un objeto, la eje¬ 
cución de un procedimiento almacenado, la adquisi¬ 
ción o liberación de un bloqueo, y el envío de un archi¬ 
vo de proceso por lotes Transact-SQL desde el cliente 
a SQL Server son eventos. Hay un conjunto de proce¬ 
dimientos almacenados del sistema para definir qué 
eventos se deberían seguir, qué datos son interesantes 
para cada evento o dónde guardar la información reco¬ 
gida por los eventos. Los filtros aplicados a los even¬ 
tos pueden reducir la cantidad de información recogi¬ 
da y almacenada. La Figura 27.3 muestra la ficha de 
eventos desde el cuadro de diálogo de definición de 
traza del Analizador de SQL. 

SQL Server proporciona más de 100 eventos pre¬ 
definidos y un usuario puede configurar 10 eventos adi¬ 
cionales. Las trazas en el lado del servidor se ejecutan 
de una forma invisible y se puede iniciar una traza de 
una forma automática cada vez que se inicia SQL Ser- 
ver. Esto garantiza que siempre se recogerá cierta infor¬ 
mación crítica y se puede utilizar como un mecanismo 
útil de auditoria. SQL Server está certificado para un 
nivel C2 de seguridad y muchos de los eventos que pue¬ 
den ser objeto de traza están disponibles exclusiva¬ 
mente para soportar requisitos C2 de certificación. 

27.1.2.3. Asistente para la optimización 
de índices 

Con todas las posibles técnicas de procesamiento de la 
consulta disponibles el optimizador de consultas puede 
determinar un plan de consulta razonablemente efecti¬ 
vo incluso en ausencia de índices bien planeados. Sin 
embargo, esto no significa que una base de datos bien 
ajustada no se beneficie de buenos índices. El diseño de 
los mejores índices posibles para las tablas en una base 
de datos grande es una tarea compleja, no solamente 


requiere un conocimiento completo de cómo SQL Ser- 
ver utiliza los índices y cómo el optimizador de con¬ 
sultas realiza sus decisiones sino cómo se utilizan real¬ 
mente los datos por las aplicaciones y consultas 
interactivas. El Asistente para optimización de índices 
de SQL Server es una herramienta poderosa para el dise¬ 
ño de los mejores índices basados en la consulta obser¬ 
vada y cargas de actualización. 

El asistente ajusta una única base de datos cada vez 
y fundamenta sus recomendaciones sobre una carga de 
trabajo que puede ser un archivo de eventos de traza 
capturados o un archivo con instrucciones SQL. El Ana¬ 
lizador de SQL está diseñado para capturar todas las 
instrucciones SQL enviadas por todos los usuarios en 
un cierto periodo de tiempo. El asistente puede enton¬ 
ces examinar los patrones de acceso a los datos para 
todos los usuarios, aplicaciones y tablas, y realizar reco¬ 
mendaciones razonables. 

27.1.3. Administrador corporativo 
de SQL Server 

Además de proporcionar acceso a las herramientas de 
diseño y visuales de bases de datos, el Administrador 
corporativo de SQL, de fácil uso, soporta administración 
centralizada de todos los aspectos de varias instalacio¬ 
nes de SQL Server, incluyendo la seguridad, eventos, 
alertas, programación, copias de seguridad, configura¬ 
ción del servidor, ajuste, búsqueda de texto completo y 
réplicas. EL Administrador corporativo de SQL Server 
permite a un administrador de la base de datos crear, 
modificar y copiar esquemas y objetos de la base de datos 
SQL Server tales como tablas, vistas y desencadenado- 
res. Debido a que se pueden organizar en gmpos varias 
instalaciones de SQL Server y ser tratadas como una uni¬ 
dad, el Administrador corporativo de SQL Server pue¬ 
de gestionar cientos de servidores simultáneamente. 

Aunque se puede ejecutar en la misma computadora 
que el motor de SQL Server, el Administrador corporati¬ 
vo de SQL Server ofrece las mismas capacidades de ges¬ 
tión cuando se ejecuta en cualquier máquina basada en 
Windows NT/2000. El Administrador corporativo de SQL 
Server también se ejecuta sobre Windows 98 aunque no 
están disponibles algunas capacidades en este entorno (es 
de mención la capacidad de utilizar el Administrador de 
control de servicios, una característica de Windows 
NT/2000, para iniciar y parar SQL Server de forma remo¬ 
ta). Además, la arquitectura eficiente cliente/servidor de 
SQL Server hace práctico el uso de capacidades de acce¬ 
so remoto (acceso telefónico a redes) de Windows NT/2000 
así como Windows 98 para la administración y gestión. 

El Administrador corporativo de SQL Server evita que 
el Administrador de la base de datos tenga que conocer 
los pasos específicos y la sintaxis para completar un tra¬ 
bajo. Proporciona más de 20 asistentes para guiar al admi¬ 
nistrador de la base de datos en el proceso de configurar 
y mantener una instalación de SQL Server. La interfaz 
del Administrador corporativo aparece en la Figura 27.4. 
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FIGURA 27.3. Ficha Eventos del cuadro de diálogo Propiedades de traza. 


¡íñ SQL Server Enterprise Manager - [Raíz de la consola\Servidores Microsoft SQL ServerVGrupo de SQL Server\PC-FERNAN 


'^¡j Consola Ventana Ayuda 


Acción Ver Herramientas j <3= | ÜD ¡0 & 0 [§* N Qí? Q ® Q 


Árbol 


Pl Raíz de la consola 
B ÜJ Servidores Microsoft SQL Server 
B ^ Grupo de SQL Server 

B 9) PC-FERNAN (Windows NT) 
B C] Bases de datos 
S U master 
El y model 
É- Ü msdb 
É-0 Northwind 

® u rüü 

É 0 tempdb 

0 CJ Servicios de transformaci 
é Q Administración 
0 Cj Duplicación 
lil P~1 Seguridad 
0 C] Servicios de compatibilid. 
É -Q Meta Data Services 


pubs 11 elementos 

General 




Info. de tabla 

Asistentes 




Base de datos 

Propietario: 

Fecha de creación: 

Tamaño: 

Espacio disponible: 

Opciones de la base de datos: 
Número de usuarios: 


Mantenimiento 


sa 

6/08/00 1:4 

2,50MB 

0,43MB 

normal 

2 


FIGURA 27.4. Interfaz del Administrador corporativo de SQL Server. 


649 


















































FUNDAMENTOS DE BASES DE DATOS 


27.2. VARIACIONES Y EXTENSIONES DE SQL 


Transact-SQL es el lenguaje de bases de datos soporta¬ 
do por SQL Server. Transact-SQL es un lenguaje com¬ 
pleto de programación de bases de datos que incluye 
instrucciones de definición y manipulación de datos, 
instrucciones iterativas y condicionales, variables, pro¬ 
cedimientos y funciones. Transact-SQL cumple el nivel 
de entrada de la norma SQL-92 pero también soporta 
varias características desde los niveles intermedios y 
superiores. Transact-SQL también soporta extensiones 
a la norma SQL-92. 

27.2.1. Tipos de datos 

SQL Server proporciona un conjunto de tipos de datos 
primitivos que definen todos los tipos de datos que se 
pueden utilizar con SQL Server. El conjunto de tipos de 
datos primitivos incluyen: 

• Un conjunto completo de tipos de enteros con sig¬ 
no con 1, 2, 4 y 8 bytes de precisión (tinyint, sma- 
llint, int y bigint) 

• Un tipo de datos bit con valores 0 o 1 (bit) 

• Tipo decimal con 38 dígitos de precisión (decimal, 
numeric) 

• Tipos de moneda con precisión de 1/1000 de la 
unidad monetaria (money, smallmoney) 

• Tipos de fecha y hora con una precisión de hasta 
3.33 milisegundos (datetime, small-datetime) 

• Tipos en coma flotante de precisión sencilla y doble 
(real, float) 

• Tipos de cadenas de caracteres de tamaño fijo y 
variable de hasta 2 30 -l caracteres Unicode y no 
Unicode (char/nchar, varchar/nvarchar, text/ntext) 

• Cadenas de bytes de tamaño fijo y variable de has¬ 
ta 2 31 -1 bytes (binary, varbinary, image) 

• Un tipo cursor que permite referencias a un obje¬ 
to cursor (cursor) 

• Tipos de datos de identificadores únicos globales 
y para la base de datos 

Además, SQL Server soporta los tipos sql_variant y 
table descritos en los apartados 27.2.1.1 y 27.2.1.2. 

27.2.1.1. Tipo Variant 

Sql_variant es un tipo de datos escalar que permite a 
una columna de una fila, variable o argumento de fun¬ 
ción contener valores de cualquier tipo escalar SQL 
(excepto text, ntext, image, rowversion y sql_variant). 
Es utilizado por aplicaciones que necesitan almacenar 
datos cuyo tipo no se puede conocer cuando se definen 
los datos. Internamente el sistema guarda el tipo origi¬ 
nal de datos. Es posible filtrar, reunir y ordenar colum¬ 


nas sql_variant. La función del sistema sql_variant_pro- 
perty puede devolver detalles sobre los datos reales 
almacenados en una columna de tipo sql_variant, inclu¬ 
yendo el tipo base e información del tamaño. 

27.2.1.2. Tipo Table 

Table es un tipo que permite a una variable guardar un 
conjunto de filas. Este tipo se utiliza principalmente para 
especificar el tipo devuelto por las funciones que devuel¬ 
ven tabla. Una variable table se comporta como una 
variable local. Tiene un ámbito bien definido, que es la 
función, procedimiento almacenado, o proceso por lotes 
en el cual se declara. Dentro de este ámbito se puede 
utilizar una variable table como una tabla normal. Se 
puede aplicar en cualquier lugar donde se utiliza una 
tabla o expresión de tabla en instrucciones select, ¡nsert, 
update y delete. 

Las variables table se limpian automáticamente al 
final de la función, procedimiento almacenado o pro¬ 
ceso por lotes en el cual se definen. Además, las varia¬ 
bles table utilizadas en procedimientos almacenados 
resultan en menos recompilaciones de estos procedi¬ 
mientos que cuando se utilizan las tablas temporales. 
Las transacciones que involucran las variables table 
duran solamente en la actualización de la variable table 
por lo que las variables table requieren menos recursos 
de bloqueos y de registro histórico. 

27.2.2. Funciones definidas por el usuario 

Las funciones definidas por el usuario permite a los mis¬ 
mos definir sus propias funciones Transact-SQL median¬ 
te el uso de la instrucción create function. SQL Server 
soporta las funciones que devuelven un tipo escalar o 
una tabla. Las funciones escalares se pueden utilizar en 
cualquier expresión escalar dentro de una instrucción 
LMD o LDD de SQL. Las funciones que devuelven 
tablas se pueden utilizar en cualquier lugar donde se 
permita una tabla en una instrucción select. Las fun¬ 
ciones que devuelven una tabla cuyo cuerpo contiene 
una única instrucción SQL select se tratan como una 
vista (entre líneas expandida) en la consulta que hace 
referencia a la función. Puesto que las funciones que 
devuelven una tabla permiten la introducción de argu¬ 
mentos, las funciones entre líneas que devuelven tablas 
se pueden considerar vistas parametrizadas. 

27.2.3. Vistas 

Una vista es una tabla virtual cuyos contenidos están 
definidos por una instrucción select. Las vistas son un 
poderoso mecanismo de modelado de datos y seguri¬ 
dad. Las vistas indexadas (Apartado 27.2.3.1) también 
pueden proporcionar un beneficio sustancial en el ren- 
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dimiento. Las tablas referenciadas por la definición de 
la vista se conocen como tablas base. En el ejemplo que 
sigue, vistatítulos es una vista que selecciona los datos 
desde tres tablas base: título, autortítulo y títulos. Estas 
tablas son parte de la base de datos ejemplo pubs inclui¬ 
da con SQL Server. 

create view vistatítulos as 

select título, au_ord, au_nombre, precio, ventas, 
id_editorial 

from autores as a join autortítulo as at on (a.au_id 
= at.au_id) 

join títulos as t on (t.título_id = at.título_id) 

Se puede hacer referencia a la vista vistatítulos en 
instrucciones de la misma forma a como se haría con 
una tabla base: 

select * 

from vistatítulos 
where precio >=30 

Una vista puede hacer referencia a otras vistas. Por 
ejemplo vistatítulos presenta información que es útil 
para administradores, pero las empresas normalmente 
revelan sus datos de venta sólo en los informes trimes¬ 
trales o anuales. Se puede constmir una vista que selec¬ 
cione todas las columnas de vistatítulos excepto au_ord 
y ventas. Esta nueva vista puede ser utilizada por los 
clientes para obtener listas de los libros disponibles sin 
ver la información financiera: 

create view Cust vistatítulos as 

select título, au_nombre, precio, id_editorial 

from vistatítulos 

Las consultas que emplean las vistas se optimizan 
expandiendo la definición de la vista en la consulta (en 
otras palabras, el optimizador basado en el coste opti¬ 
miza toda la consulta como si se hubiera realizado sin 
el uso de vistas). 

27.2.3.1. Vistas indexadas 

Además de las vistas tradicionales como se definieron en 
la norma ANSI de SQL, SQL Server soporta las vistas 
indexadas (materializadas). Las vistas indexadas pueden 
mejorar sustancialmente el rendimiento de las consultas 
complejas de ayuda a la toma de decisiones que recupe¬ 
ran un gran número de filas y agregan grandes cantida¬ 
des de información en sumas recuentos y medias. SQL 
Server soporta la creación de índices agrupados en una 
vista y subsecuentemente cualquier número de índices 
no agrupados. Una vez que se indexa una vista, el opti¬ 
mizador puede utilizar sus índices en consultas que hacen 
referencia a la vista o sus tablas base. Las consultas exis¬ 
tentes se pueden beneficiar de la eficiencia mejorada de 
la recuperación de los datos directamente de la vista inde- 
xada sin tener que ser reescrita para hacer referencia a la 


vista. Las instmcciones de actualización de las tablas base 
se propagan automáticamente a los índices de la vista. 

27.2.3.2. Vistas divididas 

Las vistas divididas se utilizan para dividir los datos 
entre varias tablas, bases de datos o ejemplares de SQL 
Server con el fin de distribuir la carga de trabajo. Si los 
datos se dividen entre varios servidores, se pueden pro¬ 
porcionar los mismos beneficios en el rendimiento que 
un agrupamiento de servidores y se puede utilizar para 
soportar las necesidades de procesamiento de los mayo¬ 
res sitios Web o centros de datos corporativos. Una tabla 
base se puede dividir en varias tablas miembro, cada 
una de las cuales tiene un subconjunto de filas de la tabla 
original. Cada servidor debe tener definición de la tabla 
dividida. Una vista dividida utiliza el operador unión 
para combinar todas las divisiones en las tablas base en 
un único conjunto de resultados que se comporta exac¬ 
tamente como una copia de la tabla original completa. 
Por ejemplo, una tabla de clientes se puede dividir entre 
tres servidores. Cada servidor debe tener una división 
de la tabla base disjunta como sigue: 

• EnServidorl: 

create table Cliente_3 3 ( 

IDCliente integer primary key 

check (IDCliente between 1 and 
32999), 

... Otras definiciones de columna) 

• En Servidor2: 

create table Cliente_66 ( 

IDCliente integer primary key 

check (IDCliente between 33000 and 
65999), 

... Otras definiciones de columna) 

• En Servidor3: 

create table Cliente_99 ( 

IDCliente integer primary key 

check (IDCliente between 66000 and 
99999), 

... Otras definiciones de columna) 

Después de crear las tablas miembro, el administra¬ 
dor de la base de datos define una vista dividida distri¬ 
buida en cada servidor, cada vista teniendo el mismo 
nombre. La vista dividida distribuida para Servidorl se 
definiría como sigue: 

create view Chentes as 

select * from BaseDeDatos.PropietarioTabla. 

Clientes_33 

unión all 

select * from Server2.BaseDeDatos.Propietario 

Tabla.Clientes_66 

unión all 

select * from Server3.BaseDeDatos.Propietario 

Tabla.Clientes_99 
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Sobre Server2 y Server3 se definirían vistas similares. 

El hecho de tener la vista definida sobre cada servi¬ 
dor permite a las consultas que hacen referencia al nom¬ 
bre de la vista dividida y distribuida ejecutarse en cada 
uno de los servidores miembro. El sistema opera como 
si en cada servidor miembro hubiera una copia com¬ 
pleta de la tabla original, aunque cada servidor tenga 
solamente una tabla miembro local y una vista dividi¬ 
da y distribuida que referencia a la tabla local y las dos 
tablas remotas. La ubicación de los datos es transpa¬ 
rente a la aplicación. Con estas tres vistas, cualquier ins¬ 
trucción Transact-SQL sobre cualquiera de los tres ser¬ 
vidores que haga referencia a Clientes verá los mismos 
resultados que desde la tabla original. Se puede acce¬ 
der a las vistas divididas no solamente mediante ins¬ 
trucciones select sino también mediante instrucciones 
insert, update y delete, incluyendo instrucciones que 
afectan a varias divisiones e incluso aquellas que requie¬ 
ren trasladar filas de una división a otra. 

27.2.3.3. Vistas actualizables 

Generalmente las vistas puede ser el objetivo de las ins¬ 
trucciones update, delete o insert si la modificación de 
los datos se aplica a solamente una de las tablas base 
de la vista. Las actualizaciones de las vistas divididas 
se pueden propagar a varias tablas base. Por ejemplo, 
la siguiente instrucción update incrementará los pre¬ 
cios para el editor «0736» en un 10 por ciento. 

update vistatítulos 

set precio = precio * 1.10 

where id_editorial = ’0736’ 

Para las modificaciones de los datos que afectan a 
más de una tabla base, la vista se puede actualizar si hay 


un desencadenador instead (Apartado 27.2.4) definido 
para la operación. Los desencadenadores insert para las 
operaciones insert, update o delete se pueden definir 
en una vista para especificar las actualizaciones que se 
deben ejecutar en las tablas base para implementar las 
modificaciones correspondientes en la vista. 

27.2.4. Desencadenadores (disparadores) 

Los desencadenadores son procedimientos Transact- 
SQL que se ejecutan automáticamente cuando se envía 
una instrucción update, insert o delete a una tabla base 
o vista. Los desencadenadores son un mecanismo que 
posibilita la aplicación de la lógica del negocio de for¬ 
ma automática cuando se modifican los datos. Los 
desencadenadores pueden extender la lógica de verifi¬ 
cación de la integridad de restricciones declarativas, 
predeterminadas y reglas, aunque las restricciones decla¬ 
rativas se deberían utilizar preferentemente siempre que 
se satisfagan las necesidades. 

Hay dos clases generales de desencadenadores que 
difieren en el tiempo con respecto a la instrucción de 
desencadenamiento, bajo la que se realiza la acción. Los 
desencadenadores after se ejecutan después de la ins¬ 
trucción de desencadenamiento y se aplican posterio¬ 
res restricciones declarativas. Los desencadenadores 
instead se ejecutan en lugar de la acción de desenca¬ 
denamiento. Los desencadenadores instead son simi¬ 
lares a los desencadenadores before, pero realmente 
reemplazan la acción de desencadenamiento. En SQL 
Server los desencadenadores after se pueden definir 
solamente sobre tablas base mientras que los desenca¬ 
denadores instead se pueden definir sobre tablas base 
o vistas. Los desencadenadores instead permiten que 
se pueda actualizar prácticamente cualquier vista. 


27.3. ALMACENAMIENTO E INDEXACIÓN 


En SQL Server una base de datos se refiere a una colec¬ 
ción de archivos que contienen datos y que son soporta¬ 
dos por un único registro histórico de transacciones. La 
base de datos es la unidad principal de administración en 
SQL Server y también proporciona un contenedor para 
estructuras físicas tales como tablas e índices y para 
estructuras lógicas tales como restricciones, vistas, etc. 

27.3.1. Grupos de archivos 

Con el fin de gestionar el espacio en una base de datos 
de forma efectiva, el conjunto de archivos en una base 
de datos se divide en grupos denominados grupos de 
archivos (filegroups). Cada grupo de archivos contiene 
uno o más archivos del sistema operativo. 

Toda base de datos tiene al menos un grupo de archi¬ 


vos conocido como el grupo de archivos primario. Este 
grupo de archivos contiene todos los metadatos de la 
base de datos en tablas del sistema. El grupo de archi¬ 
vos primario también puede contener datos de usuario. 

Si se crean grupos de archivos definidos por el usua¬ 
rio adicionales, un usuario puede controlar de forma 
explícita la ubicación de las tablas individuales, índices 
o las columnas de objetos grandes de una tabla ubicán¬ 
dolas en un grupo de archivos. Por ejemplo, el usuario 
puede elegir almacenar una tabla en el grupodearchi- 
vosA, su índice no agrupado en grupodearchivosB y las 
columnas de objetos grandes de la tabla en grupodear- 
chivosC. La ubicación de estas tablas e índices en dis¬ 
tintos grupos de archivos permite al usuario controlar 
el uso de los recursos de hardware (esto es, discos y el 
subsistema E/S). Un grupo de archivos en concreto se 
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considera siempre el grupo de archivos predetermina¬ 
do; inicialmente, el grupo de archivos predeterminado 
es el grupo de archivos primario, pero se puede dar a 
cualquier grupo de archivos definido por el usuario la 
propiedad de determinado. Si una tabla o índice no está 
ubicada específicamente en un grupo de archivos, se 
crea en el grupo de archivos predeterminado. 

27.3.2. Administración del espacio en grupos 
de archivos 

Uno de los muchos propósitos principales es permitir 
una gestión de espacio efectiva. Todos los archivos de 
datos se dividen en unidades de 8 Kbytes de espacio fijo 
denominadas páginas. El sistema de asignación es res¬ 
ponsable de asignar estas páginas a tablas e índices. El 
objetivo del sistema de asignación es minimizar la can¬ 
tidad de espacio malgastado mientras que, al mismo 
tiempo, mantener el nivel de fragmentación de la base 
de datos en el mínimo para asegurar un buen rendi¬ 
miento de exploración. Con el fin de lograr este objeti¬ 
vo el administrador de asignación normalmente asigna 
y desasigna todas las páginas en unidades de ocho pági¬ 
nas contiguas denominadas extensiones. 

El sistema de asignación gestiona estas extensiones 
mediante varios mapas de bits. Estos mapas de bits per¬ 
miten al sistema de asignación encontrar una página o 
extensión para la asignación de una forma rápida. Estos 
mapas de bits también se utilizan cuando se ejecuta una 
tabla completa o exploración de índices. La ventaja de 
usar mapas de bits basados en la asignación para la 
exploración es que permiten recorridos en el orden del 
disco de todas las extensiones que pertenecen a una tabla 
o en el nivel de las hojas de los índices, lo que mejora 
significativamente el rendimiento de la exploración. 

Si hay más de un archivo en un grupo de archivos, 
el sistema de asignación proporciona extensiones para 
cualquier objeto en ese grupo de archivos utilizando un 
algoritmo de «relleno proporcional». Cada archivo se 
rellena con la proporción de la cantidad de espacio libre 
en ese archivo comparado con otros archivos. Esto lle¬ 
na todos los archivos de un grupo de archivos aproxi¬ 
madamente con el mismo factor y permite al sistema 
utilizar todos los archivos en un grupo de archivos de 
forma equitativa. Durante una exploración que utiliza 
los mapas de bits de asignación, el algoritmo de explo¬ 
ración aprovecha los distintos archivos enviando E/S 
separadas a cada uno de los archivos. 

Una de las mayores decisiones al configurar una base 
de datos es determinar su tamaño. SQL Server permite a 
los archivos de datos cambiar su tamaño después de crear 
la base de datos. El usuario puede incluso elegir hacer 
que el archivo de datos crezca automáticamente si la base 
de datos se queda sin espacio. Por ello, el usuario puede 
configurar la base de datos a una aproximación razona¬ 
ble del tamaño esperado, pero hace que los archivos de 
la base de datos crezcan y se ajusten al patrón de uso, si 
la aproximación inicial no es correcta. SQL Server per¬ 


mite a los archivos disminuir. Con el fin de disminuir un 
archivo de datos, SQL Server traslada todos los datos des¬ 
de el fin físico del archivo a un punto más cercano al ini¬ 
cio del archivo y entonces realmente reduce el archivo, 
devolviendo el espacio al sistema operativo. 

27.3.3. Tablas 

SQL Server soporta dos organizaciones diferentes para 
las tablas: montículos e índices agrupados. En una tabla 
organizada en montículos la ubicación de cada fila de 
la tabla se determina completamente mediante el siste¬ 
ma y no es especificada de ninguna forma por el usua¬ 
rio. Las filas de un montículo tienen un identificador 
fijo como identificador de fila (R1D, Row Identifier) y 
su valor nunca cambia a no ser que se reduzca el archi¬ 
vo y la fila se traslade. Si la fila se torna lo suficiente¬ 
mente grande para no caber en la página en la que se 
insertó originalmente, el registro se mueve a un lugar 
distinto, pero se deja un resguardo en la ubicación ori¬ 
ginal de forma que el registro todavía se puede encon¬ 
trar utilizando su R1D original. 

En una organización agrupada por índices para una 
tabla, las filas de la tabla se almacenan en un árbol B+ 
ordenado mediante la clave de agrupamiento del índice. 
La clave de índice agrupado también sirve como el iden¬ 
tificador único para cada fila. La clave para un índice 
agrupado se puede definir como no único, en cuyo caso 
SQL Server agrega una columna oculta adicional para 
hacer la clave única. El índice agrupado también sirve 
como una estructura de búsqueda para identificar una 
fila de la tabla en una clave particular o explorar un con¬ 
junto de filas de la tabla con claves con un cierto rango. 

27.3.4. índices 

La forma más común de indexación son los índices no 
agmpados, que también se conocen como índices secun¬ 
darios. Estos índices son árboles B+ sobre una o más 
columnas de la tabla base. Permiten acceso eficiente de 
una fila de una tabla base basada en un criterio de bús¬ 
queda sobre las columnas indexadas. Además, las con¬ 
sultas que se refieren solamente a las columnas que están 
disponibles mediante índices secundarios se procesan 
mediante la recuperación de las páginas desde el nivel 
hoja de los índices sin tener que recuperar los datos del 
índice agrupado o montículo. 

SQL Server soporta la adición de columnas calcula¬ 
das a una tabla. Una columna calculada es una colum¬ 
na cuyo valor es una expresión, normalmente basada en 
el valor de otras columnas en esa fila. SQL Server per¬ 
mite al usuario construir índices secundarios sobre co¬ 
lumnas calculadas. 

27.3.5. Exploraciones y lectura anticipada 

La ejecución de las consultas en SQL Server pueden 
involucrar una serie de distintos modos de exploración 
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de las tablas e índices subyacentes. Éstos incluyen explo¬ 
raciones ordenadas y desordenadas, exploraciones en 
serie y paralelas, unidireccionales y bidireccionales, 
hacia delante y hacia atrás, y exploración de toda la tabla 
o índice y exploraciones de rango o filtradas. 

Cada uno de los modos de exploración tiene un meca¬ 
nismo de lectura anticipada que intenta anticiparse a las 
necesidades del plan de ejecución con el fin de reducir la 
latencia y gastos y utilizar el tiempo sin trabajo del dis¬ 


co. El algoritmo de lectura anticipada de SQL Server uti¬ 
liza el conocimiento del plan de ejecución de la consul¬ 
ta con el fin de conducir la lectura anticipada y asegu¬ 
rarse de que solamente se leen los datos que son realmente 
necesarios. Además, la cantidad de lectura anticipada se 
dimensiona de forma automática según el tamaño de la 
memoria intermedia, la cantidad de E/S que el subsiste¬ 
ma del disco puede sostener y la velocidad a la que el 
plan de ejecución puede consumir los datos. 


27.4. PROCESAMIENTO Y OPTIMIZACIÓN DE CONSULTAS 


El procesador de consultas de SQL Server está basado en 
un entorno extensible que permite una rápida incorpora¬ 
ción de nuevas técnicas de ejecución y optimización. La 
ejecución encapsula los algoritmos de procesamiento de 
datos en iteradores que se comunican entre sí utilizando 
la interfaz GetNextRow(). La optimización genera alter¬ 
nativas utilizando transformaciones en árbol y estima el 
coste de ejecución utilizando modelos detallados del com¬ 
portamiento de las selectividades e iteradores. 

27.4.1. Visión general de los procesos 
de optimización 

Las consultas complejas presentan oportunidades signi¬ 
ficativas de optimización que requieren la ordenación de 
los bloques de consulta, con selección del plan basado 
en el coste estimado. SQL Server utiliza un entorno pura¬ 
mente algebraico. El entorno de optimización de SQL 
Server se basa en el prototipo de optimizador Cascades. 
Una instmcción SQL se compila como sigue: 

• Análisis/vinculación. El optimizador analiza la 
instrucción y resuelve los nombres de tablas y 
columnas mediante el uso de catálogos. Resuelve 
e incorpora vistas para generar un árbol de opera¬ 
dores. Verifica la caché del procedimiento para ver 
si ya hay un plan para la consulta, en cuyo caso se 
evita la optimización. El árbol de operadores uti¬ 
liza un álgebra relacional extendida donde no hay 
noción de bloque de consulta o tabla derivada sino 
simplemente una combinación arbitraria de ope¬ 
radores relaciónales. 

• Simplificación/normalización. El optimizador apli¬ 
ca reglas de simplificación sobre el árbol de opera¬ 
dores para obtener un formulario normal y simpli¬ 
ficado. Estas reglas implementan transformaciones 
tales como enviar las selecciones hacia abajo y la 
simplificación de reuniones extemas en reuniones. 
Durante la simplificación, el optimizador determi¬ 
na y carga las estadísticas requeridas para la 
estimación de la cardinalidad. Si se pierden las esta¬ 
dísticas requeridas, el optimizador las crea auto¬ 
máticamente antes de continuar la optimización. 


• Optimización basada en el coste. El optimizador 
aplica la exploración e implementación de reglas 
para generar alternativas, estimar el coste de la eje¬ 
cución y elegir el plan con el coste anticipado más 
bajo. Las reglas de exploración implementan la 
reordenación de operadores, incluyendo reorde¬ 
nación de la reunión y de la agregación. Las reglas 
de implementación introducen alternativas en la 
ejecución tales como reuniones por mezcla y reu¬ 
niones por asociación. 

• Preparación del plan. El optimizador crea estruc¬ 
turas del plan de ejecución para el plan seleccio¬ 
nado. 

La optimización basada en el coste no se divide en 
fases que optimizan distintos aspectos de la consulta de 
forma independiente y no está restringida a una única 
dimensión tal como la enumeración de reuniones. En 
su lugar una colección de reglas de transformación defi¬ 
ne el espacio de interés y la estimación del coste se uti¬ 
liza uniformemente para seleccionar un plan eficiente. 

27.4.2. Simplificación de la consulta 

Durante la simplificación, el optimizador envía las selec¬ 
ciones del árbol de operadores tan abajo como sea posi¬ 
ble. Verifica los predicados en busca de contradiccio¬ 
nes teniendo en cuenta las restricciones declaradas. 
Utiliza las contradicciones para identificar subexpre¬ 
siones vacías, que se eliminan del árbol. Un escenario 
común es la eliminación de ramas unión que recuperan 
los datos de las tablas con distintas restricciones. 

Una serie de reglas de simplificación son depen¬ 
dientes del contexto, es decir, la sustitución solamente 
es válida en el contexto de la utilización de la subex¬ 
presión. Por ejemplo, una reunión externa se puede sim¬ 
plificar en una reunión interna si una operación de fil¬ 
trado posterior elimina reglas no coincidentes que se 
rellenaron con nuil. Otro ejemplo es la eliminación de 
reuniones sobre claves externas que no se necesitan eje¬ 
cutar si no hay uso posterior de las columnas desde la 
tabla referenciada. Un tercer ejemplo es el contexto de 
independencia de duplicados, que especifica que la dis- 
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tribución de una o más copias de una fila no afecta al 
resultado de la consulta. Las subexpresiones bajo semi- 
rreuniones y bajo distinct son independientes de dupli¬ 
cados, lo que permite cambiar unión a unión all. 

Para agrupar una agregación se utiliza el operador 
GbAgg, que crea gmpos y opcionalmente aplica una fun¬ 
ción de agregado sobre cada grupo. La eliminación de 
duplicados, expresado en SQL mediante la palabra cla¬ 
ve distinct es sencillamente un GbAgg sin funciones de 
agregado a calcular. Durante la simplificación, la infor¬ 
mación sobre las claves y dependencias funcionales se 
utiliza para reducir el agrupamiento de columnas. 

Las subconsultas se normalizan eliminando especi¬ 
ficaciones de consulta correlacionadas y utilizando algu¬ 
nas variantes de la reunión en su lugar. La eliminación 
de correlaciones no es una «estrategia de ejecución de 
subconsultas» sino simplemente un paso de normaliza¬ 
ción. Se consideran entonces una serie de estrategias de 
ejecución consideradas durante la optimización basada 
en el coste. 

27.4.3. Reordenación y optimización basada 
en el coste 

En SQL Server las transformaciones se integran com¬ 
pletamente en la generación basada en el coste y selec¬ 
ción de planes de ejecución. Además de la reordenación 
de la reunión intema, el optimizador de consultas emplea 
transformaciones de reordenación para los operadores 
reunión externa, semirreunión y antisemirreunión del 
álgebra relacional estándar (con duplicados, para SQL). 
GbAgg se reordena también, trasladándolo debajo de 
las reuniones siempre que sea posible. La agregación 
parcial, esto es, la introducción de un nuevo GbAgg con 
agrupación sobre un superconjunto de las columnas de 
un GbAgg que se encuentre más arriba, se considera 
debajo de las reuniones y unión all y también en pla¬ 
nes paralelos. Véanse las referencias dadas en las notas 
bibliográficas para más detalles. 

La ejecución correlacionada se considera durante la 
exploración del plan; el caso más simple es una reunión 
de búsqueda en el índice. SQL Server modela esto utili¬ 
zando Apply, que opera sobre una tabla T y una expre¬ 
sión relacional parametrizada E(t). Apply ejecuta E para 
cada fila de T, que proporciona los valores de los pará¬ 
metros. La ejecución correlacionada se considera como 
una alternativa a la ejecución, sin considerar el uso de las 
subconsultas en la formulación SQL original. Es una estra¬ 
tegia muy eficiente cuando la tabla T es muy pequeña y 
los índices soportan la ejecución parametrizada eficien¬ 
te de E(t). Además se considera la reducción del núme¬ 
ro de ejecuciones de E(t) donde hay valores de paráme¬ 
tros duplicados mediante dos técnicas: ordenar T según 
los valores de los parámetros de forma que se reutilice 
un único resultado de E(t) mientras que el valor del pará¬ 
metro no cambia, o también utilizar una tabla de asocia¬ 
ción que siga la pista del resultado de E(t) para (algún 
subconjunto) de valores anteriores del parámetro. 


Algunas aplicaciones seleccionan filas según el resul¬ 
tado de algún agregado para su grupo. Por ejemplo 
«Hallar los clientes cuyo saldo es mayor que el doble de 
la media para su segmento de mercado». La formulación 
SQL requiere una autorreunión. Durante la exploración 
se detecta este patrón y se considera la ejecución por seg¬ 
mentos como una alternativa a la autorreunión. La utili¬ 
zación de la vista materializada también se considera 
durante la optimización basada en el coste. El encaje de 
vistas interactúa con la ordenación de operadores en la 
que el uso puede que no sea aparente hasta que se reali¬ 
ce otra reordenación. Cuando se encuentra que una vista 
se ajusta a alguna subexpresión, la tabla que contiene el 
resultado de la vista se agrega como alternativa a la expre¬ 
sión correspondiente. Dependiendo de la distribución de 
datos e índices disponibles puede ser mejor o no que la 
expresión original (la selección se realizará basándose 
en la estimación del coste). 

Para estimar el coste de ejecución del plan, el mode¬ 
lo tiene en cuenta el número de filas que se esperan pro¬ 
cesar, denominado el objetivo filas, así como el núme¬ 
ro de veces que se ejecuta una subexpresión. El objetivo 
filas puede ser menor que la estimación de la cardina- 
lidad en casos tales como Apply/semijoin. Apply/semi- 
join devuelve la fila t de 7' tan pronto como E(l) produ¬ 
ce una única fila (es decir, comprueba E[t)). Por tanto, 
el objetivo filas de la salida de E(t) es 1, y los objetivos 
filas de los subárboles de E{t) se calculan para E(l) para 
este objetivo y se usan para la estimación del coste. 

27.4.4. Planes de actualización 

Los planes de actualización optimizan el mantenimien¬ 
to de índices, verifican las restricciones, aplican accio¬ 
nes en cascada y mantienen las vistas materializadas. 
Para el mantenimiento de los índices, en lugar de tomar 
cada fila y mantener todos sus índices los planes de actua¬ 
lización aplican modificaciones por índice, ordenamiento 
de filas y aplican la operación de actualización según el 
orden de la clave. Esto minimiza las operaciones E/S 
aleatorias, especialmente cuando el número de filas a 
optimizar es grande. Las restricciones se manejan con 
un operador assert, que ejecutan un predicado y envían 
un error si el resultado es false. Las restricciones de inte¬ 
gridad referencial se definen mediante predicados exist, 
los cuales se convierten en semirreuniones y se optimi¬ 
zan considerando todos los algoritmos de ejecución. 

El problema Halloween se soluciona utilizando elec¬ 
ciones basadas en el coste. El problema Halloween se 
refiere a la siguiente anormalidad: supongamos que se 
lee en orden ascendente un índice sueldo y los salarios 
se suben un 10 por ciento. Como resultado de la actuali¬ 
zación, las filas se moverán hacia arriba en el índice y se 
volverán a encontrar y actualizar de nuevo, llevándonos 
a un bucle infinito. Una forma de solventar este proble¬ 
ma es separar el procesamiento de dos fases: en primer 
lugar se leen todas las filas que se actualizarán y se hace 
una copia de ellas en algún lugar temporal, después se 
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leen de este lugar y se aplican todas las actualizaciones. 
Otra alternativa es leer desde un índice distinto donde las 
filas no se trasladarán como resultado de la actualización. 
Algunos planes de ejecución proporcionan la separación 
de las fases de forma automática, si se ordena o constru¬ 
ye una tabla de asociación en las filas a actualizar. En el 
optimizador de SQL Server la protección Halloween se 
modela como una propiedad de los planes. Se generan 
varios planes que proporcionan la propiedad requerida y 
se selecciona uno según el coste de ejecución estimado. 

27.4.5. Búsqueda parcial y heurísticas 

Los optimizadores basados en el coste se enfrentan al 
problema de la explosión del espacio de búsqueda pues¬ 
to que las aplicaciones emiten consultas que involucran 
docenas de tablas. Para solucionar esto, SQL Server uti¬ 
liza varios estados de optimización, cada uno de los cua¬ 
les utiliza transformaciones de la consulta para explo¬ 
rar regiones sucesivamente mayores del espacio de 
búsqueda. 

Hay transformaciones simples y completas diseñadas 
para la optimización exhaustiva, así como transforma¬ 
ciones inteligentes que implementan varias heurísticas. 
Las transformaciones inteligentes generan planes que 
están muy lejos en el espacio de búsqueda, mientras que 
las transformaciones sencillas exploran las cercanías. Los 
estados de optimización aplican una mezcla de ambas 
clases de optimización, en primer lugar enfatizando en 
las transformaciones inteligentes y posteriormente cam¬ 
biando a transformaciones sencillas. Se preservan los 
resultados óptimos en los subárboles, de forma que los 
estados posteriores se pueden beneficiar de los resulta¬ 
dos generados con anterioridad. Cada estado necesita 
equilibrar técnicas de generación de planes opuestas: 

• Generación exhaustiva de alternativas: para 
generar el espacio completo el optimizador debe¬ 
ría utilizar transformaciones completas, locales, 
no redundantes (una regla de transformación equi¬ 
valente a una secuencia de más transformaciones 
primitivas solamente introduce costes adiciona¬ 
les). 

• Generación heurística de candidatos: una serie 
de candidatos interesantes (seleccionados según el 
coste estimado) probablemente están lejos en tér¬ 
minos de reglas de transformación primitivas. Aquí 
las transformaciones deseadas son incompletas, 
globales y redundantes. 

La optimización se puede terminar en cualquier pun¬ 
to después de que el primer plan se haya generado. Tal 
terminación se basa en el coste estimado del mejor plan 
encontrado y el tiempo gastado ya en la optimización. 
Por ejemplo, si una consulta requiere solamente mirar 
unas pocas filas en algunos índices, se producirá rápi¬ 
damente un plan muy barato en los primeros estados, 
terminando la optimización. Este enfoque nos ha per¬ 


mitido agregar nuevas heurísticas fácilmente a lo largo 
del tiempo, sin comprometer la selección basada en el 
coste de los planes o la exploración exhaustiva del espa¬ 
cio de búsqueda, cuando es apropiado. 

27.4.6. Ejecución de la consulta 

Los algoritmos de ejecución soportan el procesamiento 
basado en la ordenación y basado en la asociación, y sus 
estructuras de datos se diseñan para optimizar el uso de 
la caché del procesador. Las operaciones de asociación 
soportan agregación y reunión básica, con una serie de 
optimizaciones, extensiones y ajuste dinámico del ses¬ 
go de datos. La operación flow-distinct es una variante 
de asociación con valores distintos (hash distinct), don¬ 
de las filas se devuelven tan pronto como se encuentra 
un nuevo valor distinto, en lugar de esperar a procesar 
toda la entrada. Este operador es efectivo para consul¬ 
tas que utilizan distinct y solicita solamente unas pocas 
filas, como con la constructora top n. Los planes corre¬ 
lacionados la ejecución de E(t), a menudo incluyendo 
varias búsquedas en el índice basadas en el parámetro 
para cada fila t de la tabla T. La preextracción asincro¬ 
na permite la emisión de varias solicitudes de búsqueda 
en el índice al motor de almacenamiento. Se implemen- 
ta de la siguiente forma: se hace una solicitud de bús¬ 
queda en el índice sin bloqueo para una fila t de T, enton¬ 
ces t se sitúa en una cola de preextracción. Se sacan las 
filas de la cola y son utilizadas por Apply para ejecutar 
E(t). La ejecución de E(t) no requiere que los datos ya 
estén listos en la memoria intermedia, pero tener buenas 
operaciones de preextracción maximiza la utilización 
del hardware e incrementa el rendimiento. El tamaño de 
la cola se determina dinámicamente como una función 
de aciertos en caché. Si no se requiere ninguna ordena¬ 
ción de las filas de salida de Apply , las filas de esta cola 
se pueden descartar para minimizar la espera en la E/S. 

La ejecución en paralelo se implementa mediante el 
operador Exchange, que gestiona varias hebras, parti¬ 
ciones o datos de difusión y alimenta los datos a varios 
procesos. El optimizador de consultas decide la ubica¬ 
ción de Exchange según el coste estimado. El grado de 
paralelismo se determina dinámicamente en tiempo de 
ejecución, según la utilización actual del sistema. 

Los planes de índices están formados de los trozos 
descritos anteriormente. Por ejemplo, se considera el 
uso de una reunión de índices para resolver las conjun¬ 
ciones de predicados (o unión de índices para las dis¬ 
yunciones), basándose en el coste. Dicha reunión se pue¬ 
de realizar en paralelo, utilizando cualquiera de los 
algoritmos de reunión del servidor. También se consi¬ 
deran reuniones de índices para el único propósito de 
ensamblar una fila con el conjunto de columnas nece¬ 
sario en una consulta, que es algunas veces más rápido 
que explorar una tabla base. Tomar identificadores de 
registros de un índice secundario y localizar la fila 
correspondiente de la tabla base es efectivamente equi¬ 
valente a ejecutar una reunión de búsqueda en índice. 
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Para ello se usan las técnicas genéricas de ejecución 
correlacionada como la preextracción asincrona. 

La comunicación con el motor de almacenamiento 
se realiza mediante OLE-DB, lo que permite acceder a 
otros proveedores de datos que implementan esta inter¬ 
faz. OLE-DB es un mecanismo utilizado para consul¬ 


tas distribuidas y remotas, que las maneja directamen¬ 
te el procesador de consultas. Los proveedores de datos 
se clasifican según el rango de funcionalidad que pro¬ 
porcionan, desde simples proveedores de conjuntos de 
filas sin capacidades de indexación a proveedores con 
soporte completo de SQL. 


27.5. CONCURRENCIA Y RECUPERACIÓN 


Los subsistemas de transacciones, registro histórico, 
bloqueos y recuperación aseguran las propiedades ACID 
esperadas de un sistema de bases de datos. 

27.5.1. Transacciones 

En SQL Server todas las instrucciones son atómicas y 
las aplicaciones pueden especificar varios niveles de 
aislamiento para cada instrucción. Las transacciones se 
utilizan para encuadrar una secuencia de instrucciones, 
haciendo el conjunto completo atómico y controlando 
su aislamiento desde otras transacciones. Una única tran¬ 
sacción puede incluir instrucciones que no solamente 
seleccionan, insertan, borrar o actualizan registros, sino 
que también crean o eliminan tablas, construyen índi¬ 
ces y realizan importaciones masivas de datos. Las tran¬ 
sacciones pueden abarcar bases de datos en servidores 
remotos. Cuando las transacciones se extienden por 
varios servidores, SQL Server utiliza un servicio del sis¬ 
tema operativo Windows, denominado coordinador de 
transacciones distribuidas (Microsoft Distributed Tran- 
saction Coordinator, MS DTC) para ejecutar un proce¬ 
samiento de compromiso de dos fases. MS DTC sopor¬ 
ta el protocolo de transacción XA y, junto con OLE-DB, 
proporciona el fundamento para transacciones ACID 
entre sistemas heterogéneos. 

27.5.1.1. Puntos de almacenamiento 

SQL Server soporta dos tipos de puntos de almacena¬ 
miento: de instrucciones y con nombre. Los puntos de 
almacenamiento de instrucciones son puntos tomados 
al comienzo de una instrucción de forma que, si una 


instrucción falla, se puede retroceder sin tener que retro¬ 
ceder toda la transacción. Un punto de almacenamien¬ 
to con nombre es una instrucción save transaction 
enviada por una aplicación que etiqueta un punto en la 
transacción. Se puede enviar una instrucción rollback 
posterior para retroceder hasta el punto con nombre. 
Un retroceso a un punto de almacenamiento no libera 
bloqueos y no se puede utilizar en transacciones dis¬ 
tribuidas. 

27.5.1.2. Opciones de concurrencia 
para actualizaciones 

SQL Server ofrece control de concurrencia optimista y 
pesimista para las operaciones de actualización. 

El control de concurrencia optimista funciona bajo 
la suposición de que los conflictos de recursos entre 
varios usuarios son poco probables (aunque no imposi¬ 
bles) y permite a las transacciones ejecutarse sin blo¬ 
quear ningún recurso. Solamente cuando se intentan 
cambiar los datos se verifican los recursos para deter¬ 
minar si han ocurrido conflictos. Si sucede un conflic¬ 
to, la aplicación debe leer los datos e intentar el cambio 
de nuevo. Las aplicaciones pueden elegir si se detectan 
los cambios comparando los valores o verificando la 
columna especial rowversion de una fila. El control de 
concurrencia optimista requiere el uso de cursores. 

El control de concurrencia pesimista bloquea los 
recursos cuando se requieren durante la duración de una 
transacción. A no ser que ocurran interbloqueos se ase¬ 
gura la finalización satisfactoria de una transacción. El 
control de concurrencia pesimista es el predeterminado 
para SQL Server. 


Recurso 

Descripción 

RID 

Identificador de fila, usado para bloquear una única fila de una tabla 

Clave 

Bloqueo de fila en un índice; protege los rangos de clave en transacciones 
secuenciables 

Página 

Página de tabla o índice de 8 Kbyte 

Extensión 

Grupo contiguo de ocho páginas de datos o de índice 

Tabla 

Tabla completa, incluyendo todos los datos e índices 

BD 

Base de datos 


FIGURA 27.5. Recursos bloqueables. 
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27.5.1.3. Niveles de aislamiento 

SQL-92 define los siguientes niveles de aislamiento, 
todos ellos soportados por SQL Server: 

• Lectura no comprometida (nivel inferior donde las 
transacciones se aíslan solamente para asegurar 
que no se leen físicamente datos cormptos). 

• Lectura comprometida (Nivel predeterminado de 
SQL Server) 

• Lectura repetible 

• Secuenciable (nivel superior, donde las transac¬ 
ciones están completamente aisladas entre sí) 

27.5.2. Bloqueos 

SQL Server proporciona bloqueos de varias granulari- 
dades que permiten que una transacción bloquee distin¬ 
tos recursos (véase la Figura 27.5, donde los recursos se 
listan en orden creciente de granularidad). Para mini¬ 
mizar el coste del bloqueo, SQL Server bloquea los recur¬ 
sos automáticamente a una granularidad apropiada para 
la tarea. El bloqueo a una granularidad menor, tal como 
filas, aumenta la concurrencia, pero tiene un coste mayor, 
puesto que se deben realizar más bloqueos si se bloquean 
muchas filas. El bloqueo a una granularidad mayor, tal 
como tablas, es costoso en términos de concurrencia 
puesto que el bloqueo de una tabla completa restringe a 
otras transacciones el bloqueo a cualquier parte de la 
tabla, pero tiene unos costes de CPU y memoria meno¬ 
res, ya que se adquieren menos bloqueos. 

Los modos de bloqueos disponibles son compartido 
(S, shared), de actualización (U, update) y exclusivo (X, 
exclusive). Los bloqueos de actualización se utilizan 
para evitar que ocurra una forma común de interblo¬ 
queo cuando varias sesiones están leyendo, bloquean¬ 
do y potencialmente actualizando recursos más tarde. 
Otros modos de bloqueo adicionales (denominados blo¬ 
queos de rango de clave) se adoptan solamente en el 
nivel de aislamiento secuenciable para bloquear el ran¬ 
go entre dos filas y un índice. 

Los bloqueos de varias granularidades requieren que 
se adquieran los bloqueos en una jerarquía estricta de 
mayor a menor granularidad. La jerarquía es la base de 
datos, tabla, página y fila. Cuando se intenta bloquear 
en un nivel superior al compartido, de actualización y 
exclusivo se usan bloqueos intencionales. 

27.5.2.1. Bloqueo dinámico 

El bloqueo de granularidad fina puede mejorar la con¬ 
currencia con el coste de ciclos de CPU y memoria extra 
para adquirir y mantener muchos bloqueos. Para muchas 
consultas una granularidad de bloqueo más burda pro¬ 
porciona mejor rendimiento sin pérdida de concurren¬ 
cia (o mínima). Los sistemas de base de datos han reque¬ 
rido tradicionalmente sugerencias de consulta y opciones 
de tabla a las aplicaciones para especificar la granula¬ 
ridad del bloqueo. Además, hay parámetros de confi¬ 


guración (frecuentemente estáticos) para gestionar cuán¬ 
ta memoria dedicar a la administración del bloqueo. 

En SQL Server la granularidad del bloqueo se opti¬ 
miza automáticamente para un rendimiento y concu¬ 
rrencia óptimos para cada índice de una consulta. Ade¬ 
más, la memoria dedicada al administrador de bloqueos 
se ajusta dinámicamente según la realimentación des¬ 
de otras partes del sistema, incluyendo otras aplicacio¬ 
nes de la máquina. 

La granularidad del bloqueo se optimiza antes de la 
ejecución de la consulta para cada tabla e índice utiliza¬ 
do en la consulta. El proceso de optimización del blo¬ 
queo tiene en cuenta el nivel de aislamiento (esto es, 
cuánto tiempo se mantienen los bloqueos), el tipo de 
exploración (rango, prueba o toda la tabla), el número 
estimado de filas a explorar, la selectividad (porcentaje 
de filas visitadas que son resultado de la consulta), den¬ 
sidad de filas (número de filas por página), tipo de ope¬ 
ración (exploración, actualización), límites del usuario 
sobre la granularidad y memoria del sistema disponible. 

La Ligura 27.6 muestra una consulta ejemplo donde 
las filas resultado se identifican mediante una explora¬ 
ción de rango de un índice y después se recuperan las 
filas desde la tabla base. Aquí se utilizan los bloqueos 
de página sobre el índice, puesto que con un rango den¬ 
so de filas del índice se requieren solamente unos pocos 
bloqueos de página. Sin embargo, las filas de la tabla 
base están dispersas por toda la tabla y por ello el blo¬ 
queo en un nivel de fila proporciona una concurrencia 
mucho mayor. En general, la optimización del bloqueo 
favorece la concurrencia en sus decisiones. Una vez se 
ejecuta una consulta, la granularidad de bloqueo se 
dimensiona automáticamente hasta el nivel de tabla si 
el sistema adquiere significativamente más bloqueos 
que los esperados por el optimizador o si la cantidad de 
memoria disponible cae y no se pueden soportar el 
número de bloqueos requeridos. 

27.5.2.2. Detección de interbloqueos 

SQL Server detecta de forma automática los interblo¬ 
queos que involucran bloqueos y otros recursos. Por 
ejemplo si la transacción A está manteniendo un blo¬ 
queo en Tabla 1 y está esperando memoria disponible y 
la transacción B tiene algo de memoria que no puede 
compartir hasta que adquiera un bloqueo sobre Tabla 1, 
la transacción presentará un interbloqueo. Las hebras y 
las memorias intermedias de comunicación también pue¬ 
den estar involucradas en los interbloqueos. Cuando 
SQL Server detecta un interbloqueo, elige como la víc¬ 
tima del interbloqueo la transacción que es menos cos¬ 
tosa de retroceder, considerando la cantidad de trabajo 
que la transacción ya ha realizado. 

Lrecuentemente la detección puede perjudicar al ren¬ 
dimiento del sistema. SQL Server automáticamente ajus¬ 
ta la frecuencia de la detección de interbloqueos a la fre¬ 
cuencia a la que están ocurriendo los interbloqueos. Si 
los interbloqueos no son frecuentes, el algoritmo de 
detección se ejecuta cada 5 segundos. Si son frecuen- 
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FIGURA 27.6. Granularidad de los bloqueos. 


tes se comenzará a verificar cada vez que una transac¬ 
ción espera un bloqueo. 

27.5.3. Registros históricos y recuperación 

SQL Server está diseñado para recuperarse de fallos del 
sistema y de los medios, y el sistema de recuperación 
se puede dimensionar a máquinas con memorias inter¬ 
medias muy grandes (100 Gbytes) y miles de unidades 
de disco. 

27.5.3.1. Registros históricos 

El registro histórico de la transacción registra todos los 
cambios realizados sobre la base de datos y almacena 
suficiente información para permitir deshacer cualquier 
cambio (retroceso) o rehacer en el caso de un fallo del 
sistema o solicitud de retroceso. 

El registro histórico es, desde un punto de vista lógi¬ 
co, un flujo potencialmente infinito de registros históri¬ 
cos identificado por números de secuencia del registro 
histórico (Log Sequence Number, LSN). Desde un pun¬ 
to de vista físico, una porción del flujo se almacena en 
archivos de registros históricos. Los registros históricos 
se guardan en los archivos de registros históricos hasta 
que se realiza una copia de seguridad y no hay necesidad 
por parte del sistema de retroceso o réplica. Los archivos 
de registro histórico crecen y disminuyen en tamaño para 
acomodarse a los registros que se tienen que almacenar. 
Adicionalmente los archivos de registro histórico se pue¬ 
den agregar a una base de datos (en nuevos discos, por 
ejemplo) mientras que el sistema se está ejecutando y sin 


bloquear ninguna operación y todos los registros histó¬ 
ricos se tratan como si fueran un archivo continuo. 

27.5.3.2. Recuperación de caídas 

El sistema de recuperación de SQL Server tiene muchos 
aspectos en común con el algoritmo de recuperación 
ARIES (véase el Apartado 17.9.6), y en este apartado 
se muestran algunas de las diferencias clave. 

SQL Server posee una opción de configuración deno¬ 
minada intervalo de recuperación, que permite a un 
administrador limitar el tiempo que SQL Server debe¬ 
ría tardar en recuperarse después de una caída. El ser¬ 
vidor ajusta dinámicamente la frecuencia en los puntos 
de comprobación para reducir el tiempo de recupera¬ 
ción. Los puntos de comprobación eliminan todas las 
páginas desfasadas de la memoria intermedia, y se ajus¬ 
tan a las capacidades del sistema E/S y a su carga de 
trabajo para eliminar de forma efectiva cualquier impac¬ 
to en las transacciones que se ejecutan. 

En el inicio, después de una caída, el sistema inicia 
varias hebras (dimensionadas automáticamente al núme¬ 
ro de UCP) para iniciar la recuperación de varias bases 
de datos en paralelo. La primera fase de la recuperación 
es un paso de análisis en el registro histórico, que cons¬ 
truye una tabla de páginas desfasadas y una lista de tran¬ 
sacciones activas. La siguiente fase es un inicio de la 
fase rehacer desde el último punto de comprobación y 
realizar todas las operaciones. Durante la fase rehacer 
se utiliza la tabla de páginas desfasadas para leer anti¬ 
cipadamente las páginas de datos. La fase final es una 
fase deshacer donde se retroceden todas las transaccio- 
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nes incompletas. La fase deshacer se divide realmente 
en dos partes puesto que SQL Server utiliza un esque¬ 
ma de recuperación en dos niveles. Las transacciones 
en el primer nivel (aquellas que involucran operaciones 
intemas tales como asignación de espacio y divisiones 
de página) se deshacen primero, seguidas por las tran¬ 
sacciones del usuario. 

27.5.3.3. Recuperación de los medios 

Las capacidades de copia de seguridad y restauración de 
SQL Server permiten la recuperación de muchos fallos, 
incluyendo la pérdida o cormpción de los medios de dis¬ 
co, errores del usuario y pérdida permanente de un ser¬ 
vidor. Además, la copia de seguridad y restauración de 
las bases de datos es útil para otros propósitos, tales como 
copiar una base de datos desde un servidor a otro y el 
mantenimiento de sistemas en espera. Los sistemas en 
espera se crean con una característica denominada envío 
del registro histórico que realizan la copia de seguridad 
continua de los registros históricos de la transacción des¬ 
de una base de datos origen y entonces copia y restaura 
dichos registros históricos a una o más bases de datos en 
espera, manteniendo las bases de datos en espera sin¬ 


cronizadas con la base de datos origen. Los sistemas en 
espera pueden funcionar en cuestión de minutos. Ade¬ 
más, un sistema en espera puede estar disponible para 
procesamiento de consultas de solo lectura. 

SQL Server posee tres modelos de recuperación dis¬ 
tintos que los usuarios pueden elegir para cada base de 
datos. Mediante la especificación de un modelo de recu¬ 
peración, el administrador declara el tipo de las capaci¬ 
dades de recuperación requeridas (tales como restaura¬ 
ción en un punto y envío del registro histórico) y las copias 
de seguridad requeridas para lograrlos. Se pueden reali¬ 
zar copias de seguridad de bases de datos, archivos, gru¬ 
pos de archivos y del registro histórico de transacciones. 
Todas las copias de seguridad son difusas y completa¬ 
mente en línea; esto es, no bloquean ninguna operación 
DML o DDL cuando se ejecutan. Las operaciones de 
copia de seguridad y restauración están muy optimiza¬ 
das y limitadas solamente por la velocidad de los medios 
en los que se realiza la copia de seguridad. SQL Server 
puede realizar copias de seguridad en disco y en dispo¬ 
sitivos de cinta (hasta 64 en paralelo) y tiene interfaces 
de programación de aplicaciones de copia de seguridad 
de alto rendimiento para que las usen productos terceros. 


27.6. ARQUITECTURA DEL SISTEMA 


Un ejemplar de SQL Server es un único proceso del sis¬ 
tema operativo que es también un punto de referencia 
para las solicitudes de ejecución de SQL. Las aplica¬ 
ciones interactúan con SQL Server mediante varias 
bibliotecas en el cliente (como ODBC y OLE-DB) con 
el fin de ejecutar SQL. 

27.6.1. Grupos de hebras en el servidor 

Con el fin de minimizar el cambio de contexto en el ser¬ 
vidor y para controlar el grado de multiprogramación, 
el proceso SQL Server mantiene un gmpo de hebras que 
ejecutan solicitudes del cliente. Cuando las solicitudes 
llegan al cliente se les asigna una hebra sobre la cual se 
ejecutan. La hebra ejecuta las instrucciones SQL envia¬ 
das por el cliente y envía el resultado de vuelta. Una vez 
que la solicitud del usuario se completa, la hebra se 
devuelve al grupo de hebras. 

Además de las solicitudes del usuario, el grupo de 
hebras también se utiliza para asignar hebras para ta¬ 
reas internas secundarias. 

• Escritor diferido (Lazywriter): esta hebra se dedi¬ 
ca a asegurar que una cierta cantidad del grupo de 
memorias intermedias está libre y disponible siem¬ 
pre para la asignación del sistema. La hebra tam¬ 
bién interactúa con el sistema operativo para deter¬ 
minar la cantidad óptima de memoria que se 
debería consumir en el proceso SQL Server. 


• Punto de comprobación: esta hebra verifica de for¬ 
ma periódica todas las bases de datos con el fin de 
mantener un rápido intervalo de recuperación para 
el inicio de las bases de datos del servidor. 

• Monitor de interbloqueo: esta hebra supervisa otras 
hebras, buscando interbloqueos en el sistema. Es 
responsable de la detección de interbloqueos y tam¬ 
bién busca una víctima con el fin de permitir pro¬ 
gresar al sistema. 

Cuando el procesador de consultas elige un plan para¬ 
lelo para ejecutar una consulta determinada puede asig¬ 
nar varias hebras que trabajen en nombre de la hebra 
principal para ejecutar la consulta. 

Puesto que la familia de sistemas operativos Win¬ 
dows NT proporciona un soporte nativo para las hebras, 
SQL Server utiliza hebras NT para su ejecución. Sin 
embargo, SQL Server se puede configurar para ejecu¬ 
tar hebras en modo usuario además de las hebras del 
núcleo en sistemas de altas prestaciones para evitar el 
coste de un cambio de contexto del núcleo en el inter¬ 
cambio de una hebra. 

27.6.2. Gestión de la memoria 

Hay muchos usos distintos de memoria en el proceso 
de SQL Server: 

• Grupo de memorias intermedias: el mayor con¬ 
sumidor de memoria en el sistema es el grupo de 
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memorias intermedias. El grupo de memorias inter¬ 
medias mantiene una caché de las páginas de la 
base de datos más recientemente utilizadas. Emplea 
un algoritmo de reemplazamiento de reloj con una 
política de robo sin fuerza, esto es, las páginas de 
la memoria intermedia con actualizaciones no com¬ 
prometidas se pueden reemplazar («robar»), y no 
se fuerza su envío a disco debido a la transacción. 
Las memorias intermedias también obedecen el 
protocolo del registro histórico de escritura anti¬ 
cipada para asegurar que la recuperación de las 
caídas y los medios es correcta. 

• Asignación de memoria dinámica: es la memo¬ 
ria que se asigna de forma dinámica para ejecutar 
solicitudes enviadas por el usuario. 

• Caché de planes y ejecución: esta caché alma¬ 
cena los planes compilados para varias consultas 
que los usuarios han ejecutado previamente en el 
sistema. Esto permite que varios usuarios com¬ 
partan el mismo plan (ahorrando memoria) y tam¬ 
bién ahorra tiempo de compilación de la consul¬ 
ta para consultas similares. 


• Concesiones de mucha memoria: para los ope¬ 
radores de consulta que consumen grandes canti¬ 
dades de memoria tales como reuniones por aso¬ 
ciación y ordenaciones. 

SQL Server utiliza un elaborado esquema de asig¬ 
nación de memoria para dividir su memoria entre los 
varios usos descritos arriba. Un único administrador de 
la memoria gestiona de forma centralizada toda la 
memoria utilizada por SQL Server. El administrador de 
memoria es responsable de la división y distribución de 
la memoria de forma dinámica entre los diversos con¬ 
sumidores de memoria del sistema. Distribuye esta 
memoria de acuerdo con un análisis del coste relativo 
de memoria para cualquier uso particular. 

El administrador de memoria interactúa con el sis¬ 
tema operativo para decidir de forma dinámica cuánta 
memoria se debería consumir de la cantidad total de 
memoria en el sistema. Esto permite que SQL Server 
sea bastante agresivo en el uso de la memoria en el sis¬ 
tema pero también devuelve la memoria al sistema cuan¬ 
do otros programas la necesita sin causar excesivos fallos 
de página. 


27.7. ACCESO A DATOS 


Este apartado describe las Interfaz de programación de 
aplicaciones (Application Programming Interface, API) 
de acceso a datos soportadas por SQL Server y cómo 
se utilizan estas API para las comunicaciones entre los 
componentes internos del servidor. 

27.7.1. API de acceso a datos 

SQL Server soporta una serie de interfaces de progra¬ 
mación de aplicaciones (API) de acceso a datos, inclu¬ 
yendo: 

• Objetos de datos ActiveX (ActiveX Data Objects, 
ADO) 

• OLE-DB 

• Conectividad abierta de bases de datos (ODBC, 
Open Database Connectivity) y las API construi¬ 
das sobre ODBC: objetos de datos remotos (Remo- 
te Data Objects, RDO) y objetos de acceso a datos 
(Data Access Objects, DAO) 

• SQL incorporado para C (Embedded SQL, ESQL) 

• La biblioteca de bases de datos heredadas para C, 
que fue desarrollada específicamente para ser usa¬ 
da con versiones anteriores de SQL Server que pre¬ 
ceden a la norma SQL-92 

• HTTP y URLs 

Las aplicaciones Internet pueden utilizar URL que 
especifican las rutas virtuales del servidor de informa¬ 


ción de Internet (US, Internet Information Server) que 
hacen referencia a una ejemplar de SQL Server. Un URL 
puede contener una consulta XPath, una instrucción 
Transact-SQL o una plantilla XML. Además de utilizar 
URL, las aplicaciones Internet también pueden utili¬ 
zar ADO o OLE-DB para trabajar con datos en la for¬ 
ma de documentos XML. 

Los desarrolladores de aplicaciones utilizan API tales 
como ADO y ODBC para acceder a las capacidades de 
SQL Server desde la capa intermedia. Algunas API tales 
como OLE-DB se utilizan internamente para integrar com¬ 
ponentes del núcleo del servidor y permitir la réplica y el 
acceso distribuido para SQL y otros orígenes extemos. 

27.7.2. Comunicación dentro de SQL Server 

El servidor de la base de datos de SQL Server tiene dos 
partes principales: el motor relacional (MR) y el motor 
de almacenamiento (MA), como se muestra en la Ligu- 
ra 27.7. La arquitectura de SQL Server claramente sepa¬ 
ra los componentes del motor relacional y de almace¬ 
namiento con el servidor y estos componentes utilizan 
interfaces OLE-DB para comunicarse entre sí. 

El procesamiento de una instrucción select que hace 
referencia solamente a tablas en bases de datos locales 
se puede describir como sigue. El motor relacional com¬ 
pila la instmcción select en un plan de ejecución opti¬ 
mizado. El plan de ejecución define una serie de opera¬ 
ciones sobre conjuntos de fila sencillos desde las tablas 
individuales o índices referenciados en la instrucción 
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FIGURA 27.7. OLE-DB como una interfaz del sistema interno de gestión de bases de datos. 


select. El conjunto de filas solicitado por el motor rela- 
cional devuelve la cantidad de datos que una tabla o índi¬ 
ce necesita para ejecutar las operaciones necesarias para 
construir el conjunto de resultados select. Por ejemplo, 
la siguiente consulta calcula el resultado de dos índices: 

select NombreEmpresa, IDPedido, FechaEnvío 
from Clientes as Cli join Pedidos as Ped 
on (Cli.IDCliente = Ped.IDCliente) 

El motor relacional solicita dos conjuntos de filas, 
uno para el índice agrupado en clientes y el otro en un 
índice no agrupado en pedidos. El motor relacional enton¬ 
ces utiliza las interfaces OLE-DB para solicitar que el 
motor de almacenamiento abra los conjuntos de filas con 
estos índices. Puesto que el motor relacional funciona 


según los pasos del plan de ejecución y necesita datos, 
utiliza OLE-DB para extraer las filas individuales de los 
conjuntos de filas. El motor de almacenamiento trans¬ 
fiere los datos desde las memorias intermedias de los 
datos hasta los operadores de ejecución de la consulta, 
la cual se ejecuta en el motor relacional. El motor rela¬ 
cional combina los datos de los conjuntos de filas del 
motor de almacenamiento en el conjunto de resultados 
final transmitido al usuario. Esta comunicación entre el 
motor relacional y el motor de almacenamiento median¬ 
te la interfaz OLE-DB permite al motor relacional pro¬ 
cesar las consultas con cualquier origen de datos que 
exponga tales interfaces. Dichos orígenes de datos pue¬ 
den ser otros sistemas SQL Server (consultas distribui¬ 
das) y otros proveedores de datos OLE-DB relaciónales 
y no relaciónales (consultas heterogéneas). 


27.8. DISTRIBUCIÓN Y RÉPLICAS 


Este apartado describe las capacidades de SQL Server 
para procesamiento de consultas distribuido y hetero¬ 
géneo, así como las réplicas. 

27.8.1. Procesamiento de consultas 
distribuidas heterogéneas 

La capacidad de consultas distribuidas heterogéneas de 
SQL Server permite las consultas transaccionales y 
actualizaciones en una serie de orígenes relaciónales y 
no relaciónales mediante proveedores de datos OLE- 
DB que se ejecutan en una o más computadoras. SQL 
Server soporta dos métodos para hacer referencia a orí¬ 
genes de datos OLE-DB heterogéneos en instrucciones 
Transact-SQL. 


El método nombres del servidor vinculados utiliza pro¬ 
cedimientos almacenados del sistema para asociar el nom¬ 
bre de un servidor con un origen de datos OLE-DB. Los 
objetos en estos servidores vinculados se pueden refe- 
renciar en instrucciones Transact-SQL utilizando el con¬ 
venio de nombres de cuatro parte descrito más adelante. 
Por ejemplo, si el nombre de un servidor vinculado de 
ServSQLDept se define en otra copia de SQL Server, la 
siguiente instmcción referencia una tabla en ese servidor: 

select * 

from ServSQLDept.Northwind.dbo.Employees 

En SQL Server se registra un origen de datos OLE- 
DB como un servidor vinculado. Una vez que se defi- 
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ne un servidor vinculado se puede acceder a sus datos 
utilizando el nombre de cuatro partes <servidor vincu¬ 
lado. <catálogo>.<esquema>.<objeto>. El siguiente 
ejemplo establece un servidor vinculado a un servidor 
Oracle mediante un proveedor OLE-DB para Oracle: 

exec sp_addlinkedserver ServOra, ’Oracle 7.3’, 
’MSDAORA’, ’OracleServer’ 

Una consulta en este servidor vinculado se expresa 
como: 

select * 

from ServOra.CORP.ADMlN.VENTAS 

Además, SQL Server soporta funciones incorpora¬ 
das parametrizadas de tipo tabla denominadas open- 
rowset y openquery, que permiten enviar consultas no 
interpretadas a un proveedor o servidor vinculado, res¬ 
pectivamente, en el dialecto soportado por el provee¬ 
dor. La siguiente consulta combina la información alma¬ 
cenada en un servidor Oracle y un Microsoft Index 
Server. Lista todos los documentos y sus autores que 
contiene las palabras Data y Access ordenadas por el 
departamento y nombre del autor. 

select e.dept, f.AutorDoc, f.NombreArchivo 
from ServOra.Corp.Admin.Empleados e, 
openquery(ArchivosEmp, 

’select AutorDoc, NombreArchivo 
from scope(«c: \ EmpDocs») 
where contains(’ «Datos» nearQ 
«Access»’)>0’) as f 
where e.nombre = f. AutorDoc 
order by e.dept, f.AutorDoc 

También se puede especificar el nombre del servidor 
vinculado en una instrucción openquery para abrir un 
conjunto de filas desde el origen de datos OLE-DB. 
El conjunto de filas se puede entonces referenciar como 
una tabla en instrucciones Transact-SQL. El método ad 
hoc de nombres de conectores se utiliza para referencias 
infrecuentes a un origen de datos. Este método utiliza 
una función de tipo tabla denominada openrowset, don¬ 
de la información necesaria para conectarse a los oríge¬ 
nes de datos se proporciona como argumentos a la fun¬ 
ción. El conjunto de filas se puede entonces referenciar 
como se referencia a una tabla en instrucciones SQL. 
Por ejemplo, la siguiente consulta accede a las explora¬ 
ciones employees almacenadas en tablas en la base de 
datos Northwind en un proveedor de datos de Microsoft 
Access. Nótese que aunque el enfoque de nombre de ser¬ 
vidor vinculado descrito anteriormente encapsula toda 
la información necesaria para conectarse a un origen de 
datos, el enfoque ad-hoc de conectores requiere que el 
usuario especifique el nombre del proveedor de datos 
(Microsoft.Jet.OLE-DB.4.0), el nombre completo de la 
mta de acceso del archivo de datos, el identificador del 


usuario, la contraseña (vacío en el ejemplo de abajo) y 
el nombre de la tabla a la que se accede. 

select * 

from openrowset(’Microsoft.Jet.OLE DB.4.0’, 
’c:\Ejemplos\ 

N orthwind.mdb ’;’Admin’;’ 
Employees) 

El motor relacional utiliza las interfaces OLE-DB 
para abrir los conjuntos de filas sobre los servidores vin¬ 
culados, para extraer las filas y para gestionar las tran¬ 
sacciones. Para cada origen de datos OLE-DB al que se 
accede como un servidor vinculado, debe estar presen¬ 
te un proveedor OLE-DB sobre el servidor en el que se 
ejecuta SQL Server. El conjunto de operaciones Tran- 
sact-SQL que se pueden utilizar en un origen de datos 
OLE-DB específico depende de las capacidades del pro¬ 
veedor OLE-DB. Siempre que es efectivo en el coste, 
SQL Server envía las operaciones relaciónales tales 
como las reuniones, restricciones, proyecciones, orde¬ 
naciones y agrupaciones mediante operaciones al ori¬ 
gen de datos OLE-DB. 

SQL Server utiliza el coordinador de transacciones 
distribuidas de Microsoft (Microsoft Distributed Tran- 
saction Coordinator) y las interfaces de transacción de 
OLE-DB del proveedor para asegurar la atomicidad de 
las transacciones sobre varios orígenes de datos. 

Veamos un escenario típico para el uso de consultas 
distribuidas. Consideremos una gran compañía de segu¬ 
ros que tiene empresas subsidiarias en varios países. 
Cada oficina regional selecciona el producto que alma¬ 
cena sus datos de ventas. La subsidiaria del Reino Uni¬ 
do almacena sus datos en Oracle, la subsidiaria en Aus¬ 
tralia almacena sus datos en Microsoft Access y la 
subsidiaria de España almacena sus datos en Microsoft 
Excel y la subsidiaria de Estados Unidos almacena sus 
datos en SQL Server. Un ejecutivo de ventas interna¬ 
cional desea un informe que liste, de forma trimestral 
por los últimos tres años, las directivas de seguros, las 
subsidiarias y los representantes de ventas con las ven¬ 
tas más altas en cada cuatrimestre. Cada una de estas 
tres consultas se puede realizar mediante una única con¬ 
sulta distribuida, que se ejecuta en SQL Server. 

27.8.2. Réplica 

La réplica de SQL Server proporciona un conjunto de 
tecnologías para copiar y distribuir los datos y objetos 
de la base de datos de una base de datos a otra y tam¬ 
bién mantener la sincronización entre las bases de datos. 

La réplica puede recoger datos corporativos desde 
sitios geográficamente dispersos para propósitos de 
informes y diseminar los datos a usuarios remotos en 
una red de área local o usuarios móviles sobre cone¬ 
xiones telefónicas o Internet. La réplica de Microsoft 
SQL Server también mejora el rendimiento de las apli¬ 
caciones dimensionando para mejorar el rendimiento 
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total de lectura entre réplicas, como es común al pro¬ 
porcionar servicios de caché de datos de la capa inter¬ 
media para sitios Web al tiempo que se mantiene la con¬ 
sistencia transaccional en el conjunto de datos duplicado. 

27.8.2.1. Modelo de réplicas 

SQL Server introdujo la metáfora Publicar-Suscribir 
para la réplica de la base de datos y extiende esta metá¬ 
fora de la industria editorial a todas sus herramientas de 
administración de réplicas y supervisión. 

• El publicador es un servidor que hace los datos dis¬ 
ponibles para la réplica a otros servidores. El publi¬ 
cador puede tener una o más publicaciones, cada 
una representando un conjunto de datos y objetos 
de la base de datos relacionados lógicamente. Los 
objetos discretos en una publicación, incluyendo 
tablas, procedimientos almacenados, funciones 
definidas por el usuario, vistas, vistas materializa¬ 
das y más, todos llamados artículos. La agregación 
de un artículo a una publicación permite la perso¬ 
nalización extensiva de la forma en la que se dupli¬ 
ca el objeto, incluyendo el nombre y propietario 
de los objetos destino, restricciones sobre las cua¬ 
les los usuarios se pueden suscribir para recibir sus 
datos y cómo se debería filtrar el conjunto de resul¬ 
tados. Por ejemplo, una tabla puede tener su con¬ 
junto de datos completo o un subconjunto de sus 
datos dividido horizontalmente haciéndolos dis¬ 
ponibles para la distribución mediante su defini¬ 
ción como un artículo. Todos los formularios de la 
réplica de SQL Server soportan la división hori¬ 
zontal y vertical desde una tabla publicada. 

• Los suscriptores son servidores que reciben los datos 
replicados de un publicador. Los suscriptores pue¬ 
den suscribir convenientemente a solamente las 
publicaciones que requieren de uno o más publica- 
dores sin considerar el número o tipo de opciones de 
réplica que implemente cada uno. Dependiendo del 
tipo de opciones de réplica seleccionado, el suscrip- 
tor se puede utilizar como una réplica de sólo lectu¬ 
ra o se pueden realizar cambios en los datos que se 
propagan automáticamente al publicador y, por con¬ 
siguiente, al resto de réplicas. Las réplicas de SQL 
Server soportan suscripciones de inserción y extrac¬ 
ción verdaderas; esto es, la programación o inicia¬ 
ción de acciones de sincronización se pueden con¬ 
trolar por el publicador o mediante sus suscriptores 
según requieran las necesidades del negocio. Los 
suscriptores también pueden volver a publicar los 
datos a los que se suscriben, dando soporte a una 
topología de réplica tan flexible como requiera la 
empresa. 

• El distribuidor es un servidor que alberga la base de 
datos de distribución y almacena algunos metadatos 
de réplica. La función del distribuidor varía, depen¬ 
diendo de las opciones de réplica seleccionadas. 


27.8.2.2. Opciones de réplica 

La réplica de Microsoft SQL Server ofrece un amplio 
espectro de elecciones de tecnología. Para decidir sobre 
las opciones de réplica apropiadas a utilizar, un diseña¬ 
dor de bases de datos debe determinar las necesidades 
de la aplicación con respecto a la operación autónoma 
del sitio involucrado y el grado de consistencia tran¬ 
saccional requerido. 

• La réplica instantánea copia y distribuye los datos 
y objetos de la base de datos exactamente como 
aparecen en un instante del tiempo. La réplica ins¬ 
tantánea no requiere un seguimiento continuo de 
los cambios, puesto que los cambios no se propa¬ 
gan de forma incremental a los suscriptores. Los 
suscriptores se actualizan con una actualización 
completa del conjunto de datos definido por la 
publicación de una forma periódica. Las opciones 
disponibles con la réplica instantánea pueden fil¬ 
trar los datos publicados y pueden permitir que los 
suscriptores modifiquen los datos replicados y pro¬ 
paguen dichos cambios al publicador. 

• Con la publicación transaccional el publicador 
propaga una instantánea de datos a los suscripto- 
res, entonces envía las modificaciones de datos 
increméntales a los suscriptores como transac¬ 
ciones e instrucciones discretas. El seguimiento 
del cambio incremental ocurre dentro del motor 
del núcleo de SQL Server, que marca las transac¬ 
ciones que afectan a los objetos replicados en el 
registro histórico de la base de datos publicadora. 
Un agente de réplica lee estas transacciones del 
registro histórico de la base de datos, aplica cual¬ 
quier lógica de división y las almacena en la base 
de datos de la distribución, que actúa como una 
cola fiable que soporta el mecanismo de almace¬ 
namiento y envío de la réplica transaccional. (Las 
colas fiables son lo mismo que las colas durade¬ 
ras descritas en el Apartado 24.1.1.) Otro proce¬ 
so de réplica, el agente de distribución que se eje¬ 
cuta o en el distribuidor (inserción) o el suscriptor 
(extracción), entonces envía los cambios a cada 
suscriptor. Al igual que la réplica instantánea, la 
réplica transaccional ofrece a los suscriptores la 
opción de realizar actualizaciones inmediatas que 
utilicen un compromiso de dos fases que reflejen 
aquellos cambios de forma consistente en el publi¬ 
cador y suscriptor. 

• La réplica por mezcla permite que cada réplica en 
la empresa funcione con total autonomía en cone¬ 
xión o sin conexión. El sistema supervisa los meta- 
datos según los cambios sobre objetos publicados 
en los publicadores y suscriptores de todas las bases 
de datos duplicadas y el agente de réplica mezcla 
estas modificaciones de los datos durante la sin¬ 
cronización entre los pares replicados y asegura la 
convergencia de los datos mediante una detección 
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y resolución automática del conflicto. El agente de 
réplica utilizado en el proceso de sincronización 
incorpora numerosas opciones de políticas de reso¬ 
lución de conflictos, y la resolución de conflictos 


personalizada se puede escribir mediante el uso de 
procedimientos almacenados o mediante el uso de 
una interfaz del modelo de objetos componente 
(Component Object Model, COM) extensible. 


27.9. CONSULTAS DE TEXTO COMPLETO SOBRE DATOS RELACIONALES 


La capacidad de texto completo en SQL Server de 
Microsoft soporta la creación y mantenimiento de índi¬ 
ces de texto completo sobre cadenas de caracteres y 
columnas de imágenes almacenadas dentro de las tablas 
SQL Server, así como búsquedas de texto completo 
basadas en estos índices. La capacidad de texto com¬ 
pleto se implementa mediante el servicio Microsoft 
Search, desarrollado independientemente de SQL Ser- 
ver, para permitir las búsquedas de texto completo en 
los datos del sistema de archivos. El primer paso hacia 
la integración del servicio de búsqueda con SQL Ser- 
ver fue transformar el servicio de búsqueda en un pro¬ 
veedor OLE-DB. Este paso permitía escribir las apli¬ 
caciones en lenguajes tales como Visual Basic y C++ 
con acceso a los datos almacenados en el sistema de 
archivos mediante el uso de ADO, y también propor¬ 
cionaba la capacidad de conectar el proveedor de texto 
completo en SQL Server como un origen de datos hete¬ 
rogéneo. El segundo paso involucraba una integración 
débilmente acoplada entre SQL Server y el servicio de 
búsqueda para permitir el indexado del texto completo 
del contenido de la tabla. Esta integración está débil¬ 


mente acoplada en el sentido en que los índices de tex¬ 
to completo se almacenan en el sistema de archivos fue¬ 
ra de la base de datos. La Ligura 27.8 ilustra la arqui¬ 
tectura general de esta integración. 

Hay dos aspectos para el soporte de texto completo: 
(1) creación de índices y mantenimiento y (2) soporte 
de la consulta. El soporte de indexado involucra la cre¬ 
ación, actualización y administración de catálogos de 
texto completo e índices definidos para una tabla o tablas 
en la base de datos. El soporte de la consulta involucra 
el procesamiento de las consultas de búsqueda de texto 
completo. Dado un predicado de texto completo, el ser¬ 
vicio de búsqueda determina las entradas en el índice 
que cumplen el criterio de selección de texto completo. 
Para cada entrada que cumple el criterio de selección, el 
componente de consulta del servicio de búsqueda devuel¬ 
ve una fila, en un conjunto de filas OLE-DB, conteniendo 
la identidad de la fila cuyas columnas coinciden con el 
criterio de búsqueda y un valor de clasificación. Este 
conjunto de filas se utiliza como entrada a la consulta 
que está siendo procesada por el motor relacional SQL, 
al igual que cualquier otro conjunto de filas originado 
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FIGURA 27.8. Integración de un componente de texto completo con un SGBD relacional. 
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de tablas o índices dentro del servidor. El motor rela- 
cional combina este conjunto de filas con la tabla base 
sobre la identidad de la fila y evalúa el plan de ejecución 
que genera el conjunto de resultados final. Los tipos de 
consultas de texto completo que soporta este esquema 
incluye la búsqueda de palabras o frases, palabras pare¬ 
cidas entre sí y formas derivadas de verbos y nombres. 

Los catálogos de texto completo e índices no se alma¬ 
cenan en una base de datos SQL Server. Se almacenan 


en archivos separados gestionados por el servicio Micro¬ 
soft Search. Los archivos del catálogo de texto com¬ 
pleto no se recuperan durante la actividad de recupera¬ 
ción de SQL Server, y no se puede realizar una copia 
de seguridad y restauración mediante el uso de las ins¬ 
trucciones backup y restore. Se deben volver a sin¬ 
cronizar los catálogos de texto completo separadamente 
después de una operación de recuperación o restaura¬ 
ción. 


27.10. ALMACENES DE DATOS Y SERVICIOS DE ANÁLISIS 


Las aplicaciones de las bases de datos requieren la trans¬ 
formación de datos de muchos orígenes en un conjun¬ 
to cohesivo y consistente de datos configurados apro¬ 
piadamente para su uso en las operaciones de los 
almacenes de datos. SQL Server 2000 proporciona una 
herramienta para tales tareas, los servicios de transfor¬ 
mación de datos (Data Transformation Services, DTS). 
DTS puede acceder a los datos desde una amplia varie¬ 
dad de orígenes y transformarlos mediante el uso de 
especificaciones de transformación incorporadas y per¬ 
sonalizadas. 

Los Servicios de análisis de SQL Server proporcio¬ 
nan un rápido acceso al almacén de datos. Los datos del 
almacén de datos se extraen, resumen, organizan y alma¬ 
cenan en estructuras multidimensionales para una rápi¬ 
da respuesta a consultas de usuarios finales. Los servi¬ 
cios de análisis también proporcionan una arquitectura 
para el acceso a la recopilación de datos. Estos datos 
también se pueden enviar al cliente en una forma mul- 
tidimensional o relacional. 

Este apartado describe brevemente DTS y el proce¬ 
samiento en conexión analítico (Online Analytical Pro¬ 
cessing, OLAP) de los servicios de análisis. 

27.10.1. Servicios de transformación de datos 

El almacén de datos es un enfoque para gestionar los 
datos en los cuales los orígenes de datos heterogéneos 
(normalmente varias bases de datos OLTP) migran a 
una base de datos homogénea separada. Los almacenes 
de datos proporcionan muchos beneficios a los usuarios 
logísticos. Los datos se organizan para facilitar consul¬ 
tas analíticas en lugar de procesamiento de transaccio¬ 
nes. Se pueden resolver las diferencias entre las estruc¬ 
turas de datos en varias bases de datos heterogéneas. 
Las reglas de transformación de datos se pueden apli¬ 
car para validar y consolidar los datos cuando éstos se 
mueven desde la base de datos OLTP operacional al 
almacén de datos. Los aspectos de seguridad y rendi¬ 
miento se pueden resolver sin requerir cambios en los 
sistemas de producción. 

Los servicios de transformación de datos (Data 
Transformation Services, DTS) de SQL Server pro¬ 


porcionan la funcionalidad para importar, exportar y 
transformar los datos entre varios orígenes de datos 
heterogéneos de forma interactiva o automáticamente 
según una planificación regular. Se accede de forma 
uniforme a todos los orígenes de datos mediante los 
proveedores OLE-DB. Las secuencias de órdenes (guio¬ 
nes) ejecutan tareas de transformación entre orígenes 
de datos fuente y destino. La extracción, transforma¬ 
ción y proceso de carga involucra en los sistemas ope- 
racionales la validación de los datos, migración de los 
datos, normalización de los datos a un dominio común 
y transformaciones de datos para asignar o resumir los 
valores. Una actividad DTS se organiza en un paque¬ 
te que incluye tres componentes: (1) los objetos de 
conexión definen cada origen de datos OLE-DB fuen¬ 
te o destino, (2) los objetos tarea definen las acciones 
específicas a ejecutar y (3) los objetos paso definen la 
secuencia en la cual se ejecutan las tareas. Los pasos 
también definen si la ejecución de una tarea es depen¬ 
diente de los resultados de una tarea anterior. Data 
Pump de DTS es un componente de servicio OLE-DB 
multienhebrado que proporciona la infraestructura para 
importar, exportar y transformar los datos entre oríge¬ 
nes de datos OLE-DB heterogéneos. Las tareas Data 
Pump de DTS permiten la invocación de programas del 
usuario que resuelven correspondencias complejas entre 
las columnas de origen y destino mientras se transfie¬ 
ren los datos. 

El procesamiento mediante una tarea Data Pump de 
DTS (Ligura 27.9) incluye la conexión a los objetos de 
conexión origen y destino, determinando las propieda¬ 
des del conjunto de filas origen (que se construye 
mediante los formatos de columna de la tabla origen o 
el resultado de ejecutar una consulta) y pasando esta 
información y una definición de todas las transforma¬ 
ciones especificadas a Data Pump de DTS. Durante la 
ejecución. Data Pump de DTS extrae las filas del ori¬ 
gen de datos y copia las columnas origen a la columna 
destino según se define en las correspondencias de trans¬ 
formación encapsuladas en las secuencias de órdenes 
del modelo de objetos componentes (COM). Cada fila 
origen transformada se inserta en el origen de datos des¬ 
tino OLE-DB. 
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FIGURA 27.9. DTS accede a varios orígenes de datos mediante OLE-DB. 


27.10.2. Servicios de procesamiento analítico 
en línea 

Los servicios OLAP de SQL Server organizan los datos 
de un almacén de datos en cubos multidimensionales 
con información resumida precalculada para propor¬ 
cionar respuestas eficientes a consultas analíticas com¬ 
plejas. El objeto principal de OLAP es el cubo, una 
representación multidimensional de los datos detalla¬ 
dos y resumidos. Un cubo consiste en un origen de datos, 
dimensiones, medidas y divisiones. Un almacén de datos 
puede soportar muchos cubos distintos. Las consultas 
multidimensionales en los cubos devuelven objetos de 
tipo conjunto de datos. 

Los servicios OLAP proporcionan capacidades clien¬ 
te y servidor para crear y gestionar datos OLAP multi¬ 


dimensionales (Figura 27.10). Las operaciones del ser¬ 
vidor incluyen la creación de cubos de datos multidi¬ 
mensionales a partir de bases de datos de almacén de 
datos relaciónales y cubos almacenados en estructuras 
de cubo multidimensionales, en bases de datos relació¬ 
nales, y en combinaciones de ambos. Los metadatos de 
estructuras cubo multidimensionales se almacenan en 
un depósito en una base de datos relacional. Las opera¬ 
ciones del cliente son proporcionadas por el servicio de 
tablas dinámicas, que es un proveedor OLE-DB que 
soporta OLE-DB para extensiones de la interfaz OLAP. 
El servicio de tablas dinámicas es un servidor OLAP en 
el proceso diseñado para proporcionar análisis de datos 
en conexión y sin conexión y acceso en conexión a datos 
OLAP. El servicio de tablas dinámicas funciona como 
un cliente de los servicios OLAP. 


27.11. XML Y SOPORTE WEB 


Muchas aplicaciones se construyen actualmente como 
sistemas distribuidos débilmente acoplados donde los 
componentes individuales (frecuentemente llamados 
servicios) se combinan entre sí. Puesto que muchos de 
estos componentes se reutilizarán para otras aplicacio¬ 
nes, la arquitectura necesita ser lo suficientemente fle¬ 
xible como para permitir que los componentes indivi¬ 
duales se unan o abandonen el conglomerado 
heterogéneo de servicios y componentes y que cambien 
su diseño interno y modelos de datos sin arriesgar toda 
la arquitectura. 

XML y el soporte Web de SQL Server simplifica la 
construcción de componentes basados en la base de 


datos y los servicios que utilizan XML para la capa de 
integración. Esta capa oculta la heterogeneidad entre 
los componentes y proporciona el pegamento que per¬ 
mite a los componentes individuales tomar parte en el 
sistema débilmente integrado. 

SQL Server proporciona mecanismos para producir 
XML a partir de datos relaciónales y para consumir 
XML y hacerlo corresponder con datos relaciónales. 
Junto con el componente de acceso HTTP en las herra¬ 
mientas de acceso al cliente, esta posibilidad permite 
que SQL Server se utilice como el proveedor de datos 
y los componentes consumidores de sitios y servicios 
Web. 
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ADO con extensiones 
OLAP 


Aplicación cliente 


FIGURA 27.10. Integración de un servidor OLAP y un SGBD relacional. 


27.11.1. Arquitectura del acceso XML a SQL 
Server 

La Figura 27.11 muestra un diagrama arquitectónico de 
bloques de alto nivel del soporte XML de SQL Server. 
Puesto que las distintas aplicaciones aplican su lógica 
de negocios en posiblemente distintas ubicaciones, la 
arquitectura proporciona acceso HTTP directo cuando 
solamente se necesita ejecutar la visualización usando 
XSLT en la capa intermedia y el resto del procesamiento 
de la lógica del negocio se puede insertar completa¬ 
mente en el cliente o en el servidor de la base de datos. 
Para arquitecturas de dos capas o donde la lógica del 
negocio se tiene que ejecutar en la capa intermedia se 
utiliza frecuentemente un acoplamiento más estrecho 
de la lógica del negocio al acceso de la base de datos 
por razones de rendimiento y programabilidad. Por ello, 
todos los accesos a las características XML es a través 
del proveedor SQL OLE-DB; esto se aplica al acceso 
ADO y también al acceso HTTP mediante la extensión 
1SAP1 al Internet Information Server (IIS). 

Existen varias formas de acceder a SQL Server 
mediante HTTP. ISAPI de SQL Server está registrado 
con IIS para gestionar los mensajes a una raíz virtual 
determinada (vroot). ISAPI recibe las solicitudes para 
esa vroot particular y después de ejecutar la autoriza¬ 
ción pasa las órdenes apropiadas a través del proveedor 
SQL OLE-DB a la base de datos. La raíz virtual, como 


parte del URL, proporciona un mecanismo de abstrac¬ 
ción que encapsula el servidor de bases de datos al que 
se accede y a los ejemplares de la base de datos, los 
derechos de acceso y los métodos de acceso habilita¬ 
dos. Los métodos de acceso principales proporcionados 
por SQL Server son el acceso con plantillas y el acce¬ 
so a vistas XML. 

Las plantillas son documentos XML que proporcio¬ 
nan una consulta parametrizada y un mecanismo de 
actualización a la base de datos. Puesto que oculta la 
consulta real (o actualización) del usuario proporciona 
el nivel de desacoplamiento que hace posible la cons¬ 
trucción de sistemas débilmente acoplados. Los ele¬ 
mentos que contienen consultas son procesados por el 
procesador de plantillas y utilizados para devolver datos 
de la base de datos como parte del documento XML 
resultante. Los elementos no reconocidos por el proce¬ 
sador de la plantilla se devuelven sin modificar. Las 
plantillas pueden contener instrucciones Transact-SQL, 
updategrams (véase el Apartado 27.11.3), consultas 
XPath o una combinación de éstas. 

Las vistas XML se definen anotando un documento 
esquema SML con la correspondencia con las tablas y 
columnas relaciónales. Las jerarquías se corresponden 
desde y a la base de datos utilizando una anotación de 
relación que expresa la reunión externa entre el padre 
y los hijos. Esta vista se puede entonces utilizar para 
consultar en el lenguaje de navegación de la base de 
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FIGURA 27.11. Visión general de la arquitectura del acceso XML a SQL Server. 


datos XPath 1.0 y para actualizarlo mediante el uso de 
updategrams. Estas características XML (así como las 
consultas XML del servidor) también son accesibles 
mediante SQL OLE-DB. Puesto que los datos XML, al 
contrario que los datos relaciónales, no se representan 
como un conjunto de fijas sino como un flujo marcado 
de datos, el proveedor OLE-DB de SQL Server se ha 
extendido con una interfaz de flujo para exponer los 
resultados XML. 

En el lado del servidor, SQL Server proporciona 
extensiones a la instrucción select que simplifica la trans¬ 
formación de datos relaciónales en XML y un meca¬ 
nismo para cortar conjuntos de filas de documentos 
XML y por ello proporciona una vista relacional sobre 
los datos XML. 

27.11.2. Secuencias de resultados SQL en XML 

Las personas familiarizadas con la escritura de consul¬ 
tas de selección SQL pueden necesitar poder generar 
XML fácilmente a partir de sus resultados de la con¬ 
sulta. Por desgracia, hay muchas formas diferentes en 
las cuales se puede realizar dicha generación de XML. 
SQL Server por consiguiente proporciona tres modos 
distintos para esto con niveles distintos de complejidad 
y capacidad de autoría XML. Los tres modos se pro¬ 
porcionan mediante una nueva cláusula select denomi¬ 
nada LOR XML. 

Los tres modos son: raw (sin formato), auto (auto¬ 
mático) y explicit (explícito). La siguiente instrucción 
muestra un ejemplo de una consulta en modo auto: 

select Clientes.IDCliente, IDCliente 

from Clientes left outer join Pedidos 


on Clientes.IDCliente = Pedidos.IDCliente 

ordered by Clientes.IDCliente 

for XML auto 

Los tres modos asignan filas a elementos y valores 
de columna a atributos. La directiva opcional elements 
en el modo auto cambia la correspondencia de todos los 
valores de columna a subelementos. Los modos raw y 
auto permiten la generación sencilla de XML a partir 
de consultas relaciónales existentes. El modo explicit 
proporciona control completo de columnas sobre el 
XML generado tomando un formulario especial de un 
conjunto de resultados relacional (denominado forma¬ 
to de tabla universal) y transformándolo a XML. Los 
tres modos canalizan los datos y así se evitan construc¬ 
ciones costosas de documentos en el servidor. 

27.11.3. Vistas XML de datos relaciónales 

El apartado anterior presentaba el enfoque centrado en 
SQL para generar XML. SQL Server también propor¬ 
ciona un mecanismo que permite la definición de vistas 
XML virtuales de la base de datos relacional, la cual se 
puede consultar y actualizar con herramientas basadas 
en XML. El mecanismo central para proporcionar vis¬ 
tas XML sobre datos relaciónales es el concepto de 
esquema anotado. Los esquemas anotados consisten en 
una descripción de esquema basada en XML de la vista 
XML expuesta (en el esquema del lenguaje XML-Data 
Reduced o W3C XML) y en anotaciones que describen 
las correspondencias de las constmcciones del esquema 
XML en las constmcciones del esquema relacional. Para 
simplificar la definición de las anotaciones cada esque¬ 
ma proporciona la correspondencia predeterminada si 
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no hay presentes anotaciones. Las correspondencias pre¬ 
determinadas asignan un atributo o un subelemento no 
complejo (uno cuyo tipo de contenido es solamente tex¬ 
to) a una columna relacional con el mismo nombre. El 
resto de elementos se corresponde con filas de una tabla 
o vista con el mismo nombre. Las jerarquías se expre¬ 
san con anotaciones. Una herramienta visual descarga- 
ble denominada SQL XML View Mapper proporciona 
una forma para especificar gráficamente las correspon¬ 
dencias y, por tanto, las anotaciones. El esquema anota¬ 
do no recupera en sí mismo ningún dato sino que sola¬ 
mente define una vista virtual proyectando una vista 
XML en tablas relaciónales. Se puede requerir ahora la 
vista en un lenguaje de consulta XML y actualizado en 
un lenguaje de actualización basado en XML. 

Las actualizaciones son soportadas por los denomi¬ 
nados updategrams de XML. Los updategrams pro¬ 
porcionan una forma intuitiva de ejecutar una transfor¬ 
mación basada en el ejemplar desde un estado anterior 
a un estado posterior mediante el uso de un control de 
la concurrencia optimista. 

27.11.4. Vistas relaciónales de XML 

En muchos casos los datos se enviarán al servidor de la 
base de datos en la forma de un mensaje XML que se 
tiene que integrar con los datos relaciónales después de 
que se ejecute algo de lógica del negocio opcional sobre 
los datos dentro de un procedimiento almacenado en el 
servidor. Esto requiere el acceso mediante programa¬ 


ción a los datos XML desde un procedimiento almace¬ 
nado. Por desgracia, ni DOM ni SAX (véase el Capítu¬ 
lo 10) proporcionan una API adecuada para tratar una 
vista relacional con los datos XML; esto es, necesita 
permitir al programador SQL descomponer un mensa¬ 
je XML en distintas vistas relaciónales. 

SQL Server proporciona mecanismo de conjuntos de 
filas en XML mediante el proveedor de conjuntos de 
filas OpenXML. La vista del conjunto de filas utiliza 
una expresión XPath (el patrón de filas) para identificar 
los nodos en el árbol del documento XML que se corres¬ 
ponderá con las filas y utiliza una expresión XPath rela¬ 
tiva (el patrón de columnas) para identificar los nodos 
que proporcionan los valores para cada columna. El pro¬ 
veedor de conjuntos de filas OpenXML puede aparecer 
en cualquier lugar en una expresión SQL donde un con¬ 
junto de filas puede aparecer como un origen de datos. 
En particular, puede aparecer en la cláusula from de 
cualquier selección. 

Una de las ventajas de esta API orientada a conjun¬ 
tos de filas para los datos XML es que incluye sobre el 
modelo relacional existente para su uso con XML y pro¬ 
porciona un mecanismo para actualizar la base de datos 
con datos en formato XML. El uso de XML en conjun¬ 
ción con OpenXML permite actualizaciones multifila 
con una única llamada a procedimiento almacenado y 
actualizaciones sobre varias tablas mediante la explo¬ 
tación de la jerarquía XML. Además permite la formu¬ 
lación de consultas que combinan las tablas existentes 
con los datos XML proporcionados. 


27.12. RESUMEN 


SQL Server de Microsoft es un paquete completo de 
gestión de datos que incluye servidor de base de datos 
relacional, búsqueda e indexación de texto completo, 
importación y exportación de datos XML, integración 
de datos distribuidos y heterogéneos, servidor de aná¬ 
lisis y cliente para OLAP y recopilación de datos, répli¬ 
cas entre almacenes de datos heterogéneos, un motor 
de transformación de datos programable y más. Por ello, 
SQL Server sirve como fundamento de la familia de 
Microsoft de productos servidores empresariales. 

Durante el tiempo en el que Microsoft ha tenido un 


control total sobre el código base (después de adquirir¬ 
lo a Sybase) ha actualizado el código base e integrado 
las últimas investigaciones prácticas en el producto. 
SQL Server 2000 (lanzado en agosto de 2000) ha redon¬ 
deado algunos de los grupos de características inicia¬ 
dos en versiones anteriores y agregado funcionalidades 
completamente nuevas, incluyendo soporte XML. 

La versión que actualmente se está implementando 
está diseñada para aumentar la facilidad de uso del pro¬ 
ducto, facilidad de desarrollo de aplicaciones, robustez, 
rendimiento y dimensionabilidad. 


NOTAS BIBLIOGRÁFICAS 


Las diferencias entre las varias ediciones de SQL Ser- 
ver se describen en Delaney [2000] y también están dis¬ 
ponibles en Web en www.microsoft.com/sql. 

En www.microsoft.com/Downloads/Release.asp? 
ReleaseID=25503 está disponible información detalla¬ 


da sobre el uso del sistema certificado C2 con SQL Ser- 
ver. 

El entorno de optimización de SQL Server está basa¬ 
do en el prototipo de optimizador Cascades, que Grae- 
fe [1995] propuso. Simmen et al. [1996] discute el esque- 
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ma para reducir las columnas de agrupación. Galindo- 
Legaria y Joshi [2001] presentan una serie de estrategias 
de ejecución que SQL Server considera durante la opti¬ 
mización basada en el coste. Información adicional sobre 
aspectos de autoajuste del servidor SQL se discuten en 
Chaudhuri et al. [1999]. Chaudhuri y Shim [1994] y Yan 
y Larson [1995] discuten la agregación parcial. Chat- 
ziantoniou y Ross [1997] y Galindo-Legaria y Joshi 
[2001] propusieron una alternativa utilizada por SQL 
Server para consultas SQL que requieren una autorreu- 
nión. Bajo este esquema el optimizador detecta el patrón 
y considera la ejecución por segmentos. Pellenkoft et al. 
[1997] discuten el esquema de optimización para gene¬ 
rar el espacio completo, donde el optimizador utiliza 
transformaciones completas, locales y no redundantes. 


Graefe et al. [1998] ofrece discusiones relaciona¬ 
das con las operaciones de asociación que soportan 
agregación y reunión básica, con una serie de optimi¬ 
zaciones, extensiones y ajuste dinámico del sesgo de 
datos. Graefe et al. [1998] presentan la idea de reunir 
índices con el único propósito de ensamblar una fila 
con el conjunto de columnas necesarias en una con¬ 
sulta. Argumenta que esto algunas veces es más rápi¬ 
do que explorar una tabla base. Blakeley [1996] y 
Blakeley y Pizzo [2001] discuten respecto a la comu¬ 
nicación con el motor de almacenamiento a través de 
OLE-DB. 

La Figura 27.11, que muestra un diagrama de blo¬ 
ques de arquitectura de alto nivel del soporte XML para 
SQL Server es de Rys [2001]. 
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DICCIONARIO BILINGÜE 


N. del T.: En este diccionario bilingüe se recogen los términos más importantes que apare¬ 
cen en el libro junto al correspondiente vocablo español para aclarar la traducción realizada, 
dado que no hay un consenso general. Esperamos que sirva de ayuda al lector en la identifica¬ 
ción tanto de los términos anglosajones como de los españoles. 

Notas: 

• El símbolo / indica polisemia. 

• Los paréntesis se usan para aclarar el contexto, o para la expansión y contracción de un acró- 
nimo. 

• 77 . indica un nombre. 

• v. indica un verbo. 

• 777 . indica género masculino. 

• /. indica género femenino. 


Inglés 

Español 

INF (First normal form) 

Primera forma normal (1FN) 

2NF (Second normal form) 

Segunda forma normal (2FN) 

2PC protocol 

Protocolo de compromiso de dos fases (C2F) 

3NF (Third normal form) 

Tercera forma normal (3FN) 

3PC protocol 

Protocolo de compromiso de tres fases (C3F) 

4GL (Fourth-generation language) 

Lenguaje de cuarta generación (L4G) 

4NF (Fourth normal form) 

Cuarta forma normal (4FN) 

Aborted 

Abortada (transacción) 

Aborted acceptable termination State 

Estado de terminación aceptable abortado 

Aborted termination State 

Estado de terminación abortado 

Abstract 

Abstracto 

Abstract data 

Datos abstractos 

Acceptable termination State 

Estado de terminación aceptable 

Access paths 

Caminos de acceso 

Access time 

Tiempo de acceso 

Access-plan-selection 

Selección del plan de acceso 

ACID properties 

Propiedades ACID 

Active documents 

Documentos activos 

Active rules 

Reglas activas 

Acyclic 

Acíclico 

Aggregation 

Agregación 

Aggregation function 

Función de agregación 

Aggregation operation 

Operación de agregación 
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Aggregation operator 

Operador de agregación 

Alerting 

Advertencia 

Alias 

Alias 

Aliases 

Alias 

Almadén Research Center 

Centro de investigación de Almadén 

American National Standards Institute (ANSI) 

Instituto de Normalización Nacional Americano 

ANSI (American National Standards Institute) 

Instituto de Normalización Nacional Americano 

Anticipatory standard 

Norma anticipativa 

Any 

Any 

API (Application programming interface) 

Interfaz de programación de aplicaciones 

Append operation 

Operación append 

Application programming interface (API) 

Interfaz de programación de aplicaciones 

Application programs 

Programas de aplicación 

Archival dump 

Volcado de archivo 

Area 

Zona 

Armstrong’s axioms 

Axiomas de Armstrong 

Arpanet 

Arpanet 

Air ay 

Array 

Ascending order 

Ascending order 

Assertion 

Aserto 

Assignment 

Asignación 

Assignment operation 

Operación asignación 

Association rules 

Reglas de asociación 

Association rules discovery 

Descubrimiento de reglas de asociación 

Assume 

Asumir 

Asymmetric fragment and replícate 

Fragmentos y réplicas asimétricos 

Asynchronous transfer rnode (ATM) 

Modo de transferencia asincrono (MTA) 

ATM (Asynchronous transfer mode) 

Modo de transferencia asincrono (MTA) 

Atom 

Átomo 

Atomic 

Atómico 

Atomic domain 

Dominio atómico 

Atomicity 

Atomicidad 

Attribute 

Atributo 

Attribute inheritance 

Herencia de atributos 

Attribute list 

Lista de atributos 

Attribute valué skew 

Sesgo de los valores de los atributos 

Attribute-defined 

Definido por atributo 

Attribute-defined design constraints 

Restricciones de diseño definidas por los atributos 

Attribute-value skew 

Sesgo de los valores 

Audio and video data 

Datos de sonido y de vídeo 

Augmentation rule 

Regla de la aumentatividad 

Authorization 

Autorización 

Authorization graph 

Grafo de autorización 
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Authorization restrictions 

Restricciones de autorización 

Average latency time 

Tiempo medio de latencia 

Average response time 

Tiempo medio de respuesta 

Average seek time 

Tiempo medio de búsqueda 

Avoidance 

Evitación 

Axiom 

Axioma 

B + -tree 

Árbol B + 

B + -tree concurrency control algorithms 

Algoritmos de control de concurrencia en árboles B + 

B + -tree concurrency-control algorithm 

Algoritmo de control de concurrencia en árboles B + 

B + -tree file organization 

+ 

Organización de archivos con árboles B 

B + -tree Índex 

índice de árbol B + 

B + -tree Índex structure 

Estructura de índice de árbol B + 

Back-end 

Sistema subyacente 

Backup coordinator 

Coordinador copia de seguridad 

Balanced 

Equilibrado 

Band join 

Reunión de banda 

Base 

Base 

Batch scaleup 

Ampliabilidad por lotes 

BCNF (Boyce-Codd normal form) 

Forma normal de Boyce-Codd (FNBC) 

Biased protocol 

Protocolo sesgado 

Big-endian form 

Orden más significativo 

Binary 

Binario 

Binary large object (blob) 

Objeto en binario de gran tamaño 

Binary search 

Búsqueda binaria 

Binary trees 

Árboles binarios 

Bitemporal relation 

Relación bitemporal 

Bit-interleaved parity organization 

Organización de paridad con bits entrelazados 

Bit-level striping 

Distribución en el nivel de bit 

Blind writes 

Escrituras a ciegas 

B-link trees 

Árboles B enlazados 

Blob (Binary large object) 

Objeto en binario de gran tamaño 

Block 

Bloque 

Block number 

Número de bloque 

Blocking 

Bloqueo 

Blocking problem 

Problema de bloqueo 

Block-interleaved parity organization 

Organización de paridad con bloques entrelazados 

Block-level striping 

Distribución en el nivel de bloque 

Block-replacement strategy 

Estrategia para la sustitución de bloques 

Body 

Cuerpo 

Bottleneck 

Cuello de botella 

Bottom-up 

Ascendente 

Bound variable 

Variable ligada 
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Bounding box 

Caja límite 

Box 

Caja 

Boyce-Codd normal form (BCNF) 

Forma normal de Boyce-Codd (FNBC) 

Browsing 

Exploración 

B-tree Índex 

índice de árbol B 

Bucket 

Cajón 

Bucket overflow 

Desbordamiento de cajones 

Bucket skew 

Atasco de cajones 

Buffer 

Memoria intermedia 

Buffer block 

Bloque de memoria intermedia 

Buffer management 

Gestión de la memoria intermedia 

Buffer manager 

Gestor de la memoria intermedia 

Build 

Construir 

Build input 

Entrada para construir 

Bully algorithm 

Algoritmo luchador 

Bus 

Bus 

By operation 

Operación by 

Byte code 

Código intermedio 

Byte-string representation 

Representación en cadenas de bytes 

Cache 

Caché 

Cache coherency 

Coherencia de caché 

Cache-coherency problem 

Problema de coherencia caché 

CAD (Computer-aided design) 

Diseño asistido por computadora 

Cali back 

Comunicar 

Call-level interface (CLI) 

Interfaz del nivel de llamadas 

Candidate key 

Clave candidata 

Canonical cover 

Recubrimiento canónico 

Cartesian product 

Producto cartesiano 

Cartesian-product operation 

Operación producto cartesiano 

Cascadeless schedules 

Planificaciones sin cascada 

Cascading of the revoke 

Retirada en cadena 

Cascading rollback 

Retroceso en cascada 

CASE (Computer-aided software engineering) 

Ingeniería del software asistida por computadora 

CD-ROM (Compact-disk read-only memory) 

Memoria sólo de lectura en disco compacto 

Cell 

Celda 

Central processing unit (CPU) 

Unidad central de procesamiento (UCP) 

Centralized approach 

Enfoque centralizado 

Centralized databases 

Bases de datos centralizadas 

CICS monitor 

Monitor CICS 

Class 

Clase 

Class extents 

Extensiones de clases 

Classification 

Clasificación 
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Classification hierarchy 

Jerarquía de clasificación 

Classification tree 

Arbol de clasificación 

CLI (Call-level interface) 

Interfaz del nivel de llamadas 

Client systems 

Sistemas clientes 

Client-server 

Cliente-servidor 

Client-server database systems 

Sistemas de bases de datos cliente-servidor 

Client-server interface protocol 

Protocolo de interfaz cliente-servidor 

Closed hashing 

Asociación cerrada 

Closed polygons 

Polígonos cerrados 

Closure 

Cierre 

Cluster (n.) 

Agrupación 

Cluster (v.) 

Agrupar 

Clustering 

Agrupamiento 

Clustering file organization 

Organización de archivos en agrupaciones 

Clustering Índex 

índice con agrupación 

Coalesce 

Fusionar 

Coalescence 

Fusión 

Coalescence rule 

Regla de la fusión 

Coarse granularity 

Granularidad gruesa 

Coarse-granularity parallelism 

Paralelismo de grano grueso 

CODASYL DBTG 1991 databases 

Bases de datos CODASYL DBTG 1991 

Collection type 

Tipo colección 

Combine 

Combinar 

Combined tables 

Tablas combinadas 

Command 

Orden 

Commit 

Comprometer 

Commit log record 

Registro de compromiso del registro histórico 

Commit protocol 

Protocolo de compromiso 

Commited 

Comprometido 

Commited termination State 

Estado de terminación comprometido 

Commited transaction 

Transacción comprometida 

Commitment 

Compromiso 

Committed acceptable termination State 

Estado de terminación aceptable comprometido 

Comrnon hash prefix 

Prefijo común de la función de asociación 

Comrnon object request broker architecture (CORBA) 

Arquitectura común de agente para peticiones de objetos 

Comrnon subexpressions 

Subexpresiones comunes 

Compact-disk read-only mernory (CD-ROM) 

Memoria sólo de lectura en disco compacto 

Comparison 

Comparación 

Compatibility function 

Función de compatibilidad 

Compatible 

Compatible 

Compensating transaction 

Transacción compensadora 

Complementation rule 

Regla de la complementariedad 
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Complete 

Completo 

Complete rules 

Reglas completas 

Completeness constraint 

Restricción de completitud 

Complex 

Complejo 

Complex interactive transaction 

Transacción interactiva compleja 

Complex object 

Objeto complejo 

Complex queries types 

Consultas con tipos complejos 

Complex types 

Tipos complejos 

Component 

Componente (m.) 

Composite 

Compuesto 

Composite attributes 

Atributos compuestos 

Composite Índex 

índice compuesto 

Composite object 

Objeto compuesto 

Composition of relational operations 

Composición de operaciones relaciónales 

Computed-aided design (CAD) 

Diseño asistido por computadora 

Computer application 

Aplicación informática 

Computer network 

Red de computadoras 

Computer Science Technical Report Index 

índice de informes técnicos de informática 

Computer system 

Sistema informático 

Computer-aided software engineering (CASE) 

Ingeniería del software asistida por computadora 

Computer-aided-design (CAD) databases 

Bases de datos para diseño asistido por computadora (CAD) 

Conceptual 

Conceptual 

Conceptual level 

Nivel conceptual 

Conceptual-design 

Diseño conceptual 

Concurrency components 

Componentes de concurrencia 

Concurrency control 

Control de la concurrencia 

Concurrency control B + -trees algorithm 

Algoritmo para control de la concurrencia para los árboles B + 

Concurrency-control component 

Componente de control de concurrencia 

Concurrency-control manager 

Gestor de control de concurrencia 

Concurrency-control protocol 

Protocolo de control de la concurrencia 

Concurrency-control schemes 

Esquemas de control de concurrencia 

Condition box 

Caja de condición 

Condition-defined design constraints 

Restricciones de diseño definidas por las condiciones 

Conditions-defined constraints 

Restricciones con condiciones definidas 

Confidence 

Confianza 

Conflict equivalent 

Equivalente en cuanto a conflictos 

Conflict schedules 

Planificaciones de conflictos 

Conflict serializability 

Secuencialidad en cuanto a conflictos 

Conflict serializable 

Secuenciable en cuanto a conflictos 

Confluent 

Confluente 

Conjunctive selection 

Selección conjuntiva 

Conjunctive selection by intersection of identifiers 

Selección conjuntiva mediante la intersección de identificadores 
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Conjunctive selection using composite Índex 

Selección conjuntiva utilizando un índice compuesto 

Conjunctive selection using one Índex 

Selección conjuntiva utilizando un índice 

Consistency 

Consistencia 

Consistency constraints 

Restricciones de consistencia 

Constraints completeness 

Restricciones de completitud 

Constructed graph 

Grafo construido 

Constructor 

Constructora 

Containment hierarchy 

Jerarquía de continentes 

Contains 

Contiene 

Context switch 

Cambio de contexto 

Contiguously 

De manera contigua 

Continuous connection 

Conexión continua 

Continuous-media data 

Datos de medios continuos 

Convenient 

Práctico 

Coordinator-failure protocol 

Protocolo de fallo del coordinador 

CORBA (Common object request broker architecture) 

Arquitectura común de agente para peticiones de objetos 

Cost of parallel evaluation of operations 

Coste de la evaluación paralela de operaciones 

Cost-based optimization 

Optimización basada en el coste 

Count aggregate function 

Función de agregación count 

CPU (Central processing unit) 

Unidad central de procesamiento (UCP) 

Crash 

Caída 

Crash-recovery subsystem 

Subsistema de recuperación de caídas 

Cross join 

Reunión cruzada 

Cross-tab 

Tabla cruzada 

Cross-tabulation 

Tabla de entradas cruzadas 

Current page table 

Tabla de páginas actual 

Cursor stability 

Estabilidad del cursor 

Checkin 

Marcar 

Checkout 

Desmarcar 

Checkpoint 

Punto de revisión 

Checksum 

Comprobación de suma 

Child (or rnember) 

Hijo (o miembro) 

DAG (Directed acyclic graph) 

Grafo acíclico dirigido (GAD) 

Dangling 

Colgante 

Dangling pointer 

Puntero colgante 

Data abstraction 

Abstracción de datos 

Data archival 

Almacenamiento de datos 

Data broadcast 

Difusión de datos 

Data caching 

Almacenamiento de datos en caché 

Data consistency 

Consistencia de los datos 

Data dictionary 

Diccionario de datos 

Data directory 

Directorio de datos 
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Data encapsulating 

Encapsulamiento de datos 

Data encryption standard (DES) 

Norma de cifrado de datos 

Data fragmentation 

Fragmentación de datos 

Data inconsistency 

Inconsistencia de datos 

Data independence 

Independencia de datos 

Data integrity 

Integridad de los datos 

Data manipulation 

Manipulación de datos 

Data mining 

Recopilación de datos 

Data model 

Modelo de datos 

Data naming 

Denominación de datos 

Data parallelism 

Paralelismo de datos 

Data partitioning 

División de datos 

Data pollution 

Contaminación de los datos 

Data redundancy 

Redundancia de datos 

Data replication 

Réplica de datos 

Data storage 

Almacenamiento de datos 

Data striping 

Distribución de datos 

Data structure definition 

Definición de las estructuras de datos 

Data structure diagram 

Diagrama de la estructura de datos 

Data transfer failure 

Fallo en la transferencia de datos 

Data transmission cost 

Coste de la transmisión de datos 

Data visualization 

Visualización de datos 

Data warehouse 

Almacén de datos 

Database (DB) 

Base de datos (BD) 

Database active system 

Sistema de bases de datos activas 

Database administrator (DBA) 

Administrador de la base de datos (ABD) 

Database applications 

Aplicaciones de bases de datos 

Database buffer 

Memoria intermedia de la base de datos 

Database CAD 

CAD de bases de datos 

Database design 

Diseño de bases de datos 

Database graph 

Grafo de la base de datos 

Database instance 

Ejemplar de la base de datos 

Database integrity 

Integridad de las bases de datos 

Database management system (DBMS) 

Sistema gestor de bases de datos (SGBD) 

Database schema 

Esquema de la base de datos 

Database security 

Seguridad de la base de datos 

Database System Concepts 

Fundamentos de bases de datos 

Database Task Group 

Grupo de trabajo sobre bases de datos 

Database tree 

Árbol de la base de datos 

Database-standard specification 

Especificación de una norma para las bases de datos 

Data-cube operator 

Operador data-cube 

Data-definition language (DDL) 

Lenguaje de definición de datos (LDD) 
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Data-item utilization 

Utilización de elementos de datos 

Datalog 

Datalog 

Datalog language fixpoint 

Punto fijo del lenguaje Datalog 

Datalog language recursion 

Recursividad del lenguaje Datalog 

Datalog language rules 

Reglas del lenguaje Datalog 

Datalog rules 

Reglas de Datalog 

Data-manipulation language (DML) 

Lenguaje de manipulación de datos (LMD) 

Data-server systems 

Sistemas servidores de datos 

Data-structure diagram 

Diagrama de estructura de datos 

Data-transfer rate 

Velocidad de transferencia de datos 

Data-visualization systems 

Sistemas de visualización de datos 

DB (Database) 

Base de datos (BD) 

DBA (Database administrator) 

Administrador de bases de datos (ABD) 

DBMS (Database management system) 

Sistema gestor de bases de datos (SGBD) 

DBTG set 

Conjunto DBTG 

DDL (Data-definition language) 

Lenguaje de definición de datos (LDD) 

De facto standard 

Norma de facto 

Deadline 

Tiempo límite 

Deadlock 

Interbloqueo 

Deadlock detection 

Detección de interbloqueos 

Deadlock handling 

Tratamiento de interbloqueos 

Deadlock prevention 

Prevención de interbloqueos 

Deadlock recovery 

Recuperación de interbloqueos 

Deadlock-detection algorithm 

Algoritmo para la detección de interbloqueos 

Deadlock-detention and deadlock-recovery scheme 

Esquema de detección y recuperación de interbloqueos 

Deadlock-handling algorithm 

Algoritmo para el tratamiento de interbloqueos 

Deadlock-prevention protocol 

Protocolo de prevención de interbloqueos 

Decision-support queries 

Consultas de ayuda para las decisiones 

Decision-support systems 

Sistemas de ayuda para las decisiones 

Decompose 

Descomponer 

Decomposition 

Descomposición 

Decomposition rule 

Regla de la descomposición 

Decoupled 

Desacoplada 

Decrypt 

Descifrar 

Deferred 

Diferida 

Deferred modification 

Modificación diferida 

Degree 

Grado 

Degree of relevance 

Grado de relevancia 

Degree-two consistency 

Consistencia de grado dos 

Delete 

Borrar 

Delete operation 

Operación delete 

Deletion 

Borrado 
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Demand-driven pipelining 

Encauzamiento bajo demanda 

Dense Índex 

índice denso 

Dependency graph 

Grafo de dependencia 

Dependency preservation 

Conservación de las dependencias 

Dependency-preserving decomposition 

Descomposición con conservación de las dependencias 

Dependency-preserving decomposition 

Descomposición que conserva las dependencias 

Dependent joins 

Reuniones dependientes 

Dereference 

Desreferenciar 

Dereferencing 

Desreferenciación 

Derived attributes 

Atributos derivados 

Derived relations 

Relaciones derivadas 

DES (Data encryption standard) 

Norma de cifrado de datos 

Descending order 

Orden descendente 

Descriptive attributes 

Atributos descriptivos 

Design constraints 

Restricciones de diseño 

Design databases 

Bases de datos para diseño 

Destructor 

Destructor 

Deswizzling 

Devolución 

Difference rule 

Regla de la diferencia 

Digital signature 

Firma digital 

Digital video disk (DVD) 

Videodisco digital (VDD) 

Direct-access storage 

Almacenamiento de acceso directo 

Directed acyclic graph (DAG) 

Grafo acíclico dirigido (GAD) 

Discriminator 

Discriminante 

Disjoint subtrees 

Subárboles disjuntos 

Disjointness constraint 

Restricción sobre el carácter disjunto 

Disjunctive selection 

Selección disyuntiva 

Disjunctive selection by unión of identifiers 

Selección disyuntiva mediante la unión de identificadores 

Disk arm 

Brazo del disco 

Disk buffer 

Memoria intermedia de disco 

Disk controller 

Controlador de disco 

Disk failure 

Fallo de disco 

Disk mirroring 

Discos imagen 

Disk storage 

Almacenamiento en disco 

Disk-arm-scheduling 

Planificación del brazo del disco 

Display 

Visualizar 

Distributed data 

Datos distribuidos 

Distributed database Systems 

Sistemas distribuidos de bases de datos 

Distributed environment 

Entorno distribuido 

Distributed Gopher information Systems 

Sistemas distribuidos de información Gopher 

Distributed hypertext Systems 

Sistemas distribuidos de hipertexto 

Distributed information systems 

Sistemas distribuidos de información 
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Distributed Internet information systems 

Sistemas distribuidos de información en Internet 

Distributed query processing 

Procesamiento distribuido de consultas 

Distributed transaction model 

Modelo de transacciones distribuidas 

Distributed virtual-memory 

Memoria virtual distribuida 

Distributed virtual-memory architecture 

Arquitecturas distribuidas de memoria virtual 

Distributed World Wide Web information systems 

Sistemas distribuidos de información World Wide Web 

División 

División 

División operation 

Operación división 

DKNF (Domain-key normal form) 

Forma normal de dominios y claves (FNDC) 

DML (Data-manipulation language) 

Lenguaje de manipulación de datos (LMD) 

DML precompiler 

Precompilador del LMD 

Document 

Documento 

Domain 

Dominio 

Domain constraints 

Restricciones de dominio 

Domain relational calculus 

Cálculo relacional de dominios 

Domain types 

Tipos de dominios 

Domain variable 

Variable de dominio 

Domain-key normal form (DKNF) 

Forma normal de dominios y claves (FNDC) 

Domain-key normal form (DKNF) database 

Base de datos en forma normal de dominios y claves (FNDC) 

Dominant entity 

Entidad dominante 

Downsizing 

Fraccionamiento de costes 

Drill down 

Concreción 

Drop 

Eliminar 

Drop indices 

Supresión de índices 

Dummy 

Ficticio 

Dummy junction type 

Tipo de conexión ficticia 

Dummy link type 

Tipo de enlace ficticio 

Dummy record type 

Tipo de registro ficticio 

Dump (n.) 

Volcado 

Dump (v.) 

Volcar 

Duplicate elimination 

Eliminación de duplicados 

Durability 

Durabilidad 

DVD (Digital video disk) 

Videodisco digital (VDD) 

Dynamic 

Dinámico 

Dynamic hashing 

Asociación dinámica 

Dynamic hashing techniques 

Técnicas de asociación dinámica 

Eager 

Impaciente 

ECC (Memory-style error-correcting-code organization) 

Organización de códigos de corrección de errores tipo memoria 

Edge 

Arco 

EEPROM (Electrically erasable programmable read-only 
memory) 

Memoria sólo de lectura programable y borrable eléctricamente 

Efficient 

Eficiente 
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Election 

Elección 

Election algorithm 

Algoritmo de elección 

Electrically erasable programmable read-only memory 
(EEPROM) 

Memoria sólo de lectura programable y borrable eléctricamente 

Elevator algorithm 

Algoritmo del ascensor 

Embedded 

Incorporado 

Embedded language 

Lenguaje incorporado 

Embedded query language 

Lenguaje de consulta incorporado 

Embedded SQL language 

Lenguaje SQL incorporado 

Encapsulating 

Encapsulamiento 

Encina monitor 

Monitor Encina 

Encrypt 

Cifrar 

Encryption 

Cifrado 

Encryption key 

Clave de cifrado 

End-of-record 

Fin-de-registro 

Enterprise schema 

Esquema de la empresa 

Entity 

Entidad 

Entity set 

Conjunto de entidades 

Entity-relationship attribute inheritance 

Herencia de atributos entidad-relación 

Entity-relationship data model 

Modelo de datos entidad-relación 

Entity-relationship database schema 

Esquema de bases de datos entidad-relación 

Entity-relationship diagram 

Diagrama entidad-relación 

Entity-relationship generalization 

Generalización entidad-relación 

Entity-relationship model 

Modelo entidad-relación 

Equality 

Igualdad 

Equality on key 

Igualdad basada en la clave 

Equality on nonkey 

Igualdad basada en un atributo no clave 

Equality-generating dependency 

Dependencia de generación de igualdad 

Equi-join 

Equirreunión 

Equivalence rules 

Reglas de equivalencia 

Equivalent views 

Vistas equivalentes 

E-R diagram 

Diagrama E-R 

E-R model (Entity-relationship model) 

Modelo E-R (entidad-relación) 

Escalable system 

Sistema ampliable 

Estimate 

Estimar 

Ethernet 

Ethernet 

Evaluation algorithms queries 

Algoritmos de evaluación de consultas 

Evaluation primitives 

Primitivas de evaluación 

Event 

Evento/Suceso 

Event-condition-action model 

Modelo suceso-condición-acción 

Example element 

Elemento ejemplo 

Example rows 

Filas ejemplo 
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Except operation 

Operación except 

Exclusive lock 

Bloqueo exclusivo 

Exclusive mode lock 

Bloqueo en modo exclusivo 

Exchange-operator model 

Modelo de operador de intercambio 

Execution of workflows 

Ejecución de los flujos de trabajo 

Execution skew 

Sesgo de ejecución 

Execution States 

Estados de ejecución 

Existence dependencies 

Dependencias de existencia 

Existence dependency 

Dependencia de existencia 

Explicit 

Explícito 

Extendable hashing 

Asociación extensible 

Extensión 

Extensión 

Extemal 

Extemo 

Extemal merge-sort algorithm 

Algoritmo de mezcla-ordenación extema 

Extemal sorting 

Ordenación externa 

Extemal sort-merge 

Mezcla-ordenación extema 

Extemal variable 

Variable extema 

Extraneous 

Raro 

Fact 

Hecho 

Fail-stop assumption 

Supuesto de fallo-parada 

Failure detection 

Detección de fallos 

Failure recovery 

Recuperación de fallos 

Failure-atomicity 

Atomicidad ante fallos 

False cycles 

Ciclos falsos 

False drop 

Omisión incorrecta 

False positive 

Inclusión innecesaria 

Fan-out 

Grado de salida 

Fault tolerance 

Tolerancia ante fallos 

File 

Archivo 

File grid 

Archivo en retícula 

File header 

Cabecera de archivo 

File organization 

Organización de archivos 

File organization techniques 

Técnicas de organización de archivos 

File sean 

Explorador de archivo 

File stmeture 

Estructura de archivos 

File system 

Sistema de archivos 

File transfer protocol (FTP) 

Protocolo de transferencia de archivos 

File-processing system 

Sistema de procesamiento de archivos 

Fine granularity 

Granularidad fina 

Fine-grain machine 

Máquina de grano fino 

Fine-granularity parallel machines 

Máquinas paralelas de grano fino 

First normal form (INF) 

Primera forma normal (1FN) 
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Fixed-head disk 

Disco de cabezas fijas 

Fixed-length records 

Registros de longitud fija 

Fixed-length representation 

Representación en longitud fija 

Fixpoint 

Punto fijo 

Flash memory 

Memoria flash 

Floppy disks 

Disquetes 

Forced output 

Salida forzada 

Foreign key 

Clave extema 

Forest protocol 

Protocolo de bosque 

Forrn 

Formulario 

Form interface 

Interfaz para formularios 

Formal standard 

Norma formal 

Fortran 

Fortran 

Forwarding address 

Dirección de entrega 

Fourth normal form (4NF) 

Cuarta forma normal (4FN) 

Fourth-generation language (4GL) 

Lenguaje de cuarta generación (L4G) 

Fragment (n.) 

Fragmento 

Fragment (y.) 

Fragmentar 

Fragment and replícate 

Fragmentos y réplicas 

Fragment-and-replicate join 

Reunión con fragmentos y réplicas 

Fragmentation 

Fragmentación 

Frame-memory model 

Modelo de memoria por marcos 

Free list 

Lista libre 

From operation 

Operación from 

Front-end 

Parte visible al usuario 

FTP (File transfer protocol) 

Protocolo de transferencia de archivos 

Fudge factor 

Factor de escape 

Full outer join 

Reunión extema completa 

Full replication 

Réplica completa 

Full-text Índex 

índice del texto completo 

Fully distributed deadlock-detection algorithm 

Algoritmo de detección de interbloqueos completamente 
distribuido 

Function hashing 

Asociación de funciones 

Functional dependencies 

Dependencias funcionales 

Functional dependency 

Dependencia funcional 

Fuzzy 

Difuso 

Fuzzy checkpoint 

Punto de revisión difuso 

Fuzzy durnp 

Volcado difuso 

Fuzzy durnp schemes 

Esquemas de volcado difuso 

Gamma System 

Sistema Gamma 

Garbage 

Basura 

Garbage collection 

Recogida de basura 
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General constraint 

Restricción general 

Generalized-projection 

Proyección generalizada 

Generalized-projection operation 

Operación proyección generalizada 

Geographic data 

Datos geográficos 

Geographic databases 

Bases de datos geográficas 

Geographic information Systems 

Sistemas de información geográfica 

Geometric information 

Información geométrica 

Global positioning System (GPS) 

Sistema de localización global 

Global transaction 

Transacción global 

Global-read protocol 

Protocolo de lectura global 

Global-read-write protocol 

Protocolo global de lectura y escritura 

Global-read-write/local-read protocol 

Protocolo de lectura y escritura global y lectura local 

Gopher 

Gopher 

GPS (Global positioning System) 

Sistema de localización global 

Grace system 

Sistema Grace 

Grant 

Concesión 

Grant operation 

Operación grant 

Granting of locks 

Concesión de bloqueos 

Granting of privileges 

Concesión de privilegios 

Granularity 

Granularidad 

Granularity locks 

Granularidad de los bloqueos 

Graph 

Grafo 

Graph precedence 

Precedencia de grafos 

Graph-based protocol 

Protocolo basado en grafos 

Graphical data 

Datos gráficos 

Graphical user interface 

Interfaz gráfica de usuario 

Grid array 

Array en retícula 

Grid file 

Archivo en retícula 

Ground instantation 

Ejemplar básico 

Ground instantiation of a rule 

Ejemplar básico de una regla 

Group 

Grupo 

Group by operation 

Operación group by 

Group-commit technique 

Técnica de compromiso en grupo 

Grouping 

Agrupación 

Growing phase 

Fase de crecimiento 

Gupta SQL languages 

Lenguaje SQL Gupta 

Handoff 

Relevo 

Handoff of control 

Relevo del control 

Hard disk 

Disco rígido 

Hardware swizzling 

Rescate hardware 

Harmonic mean 

Media armónica 

Hash 

Asociar 
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Hash function 

Función de asociación 

Hash Índex 

índice asociativo 

Hash partitioning 

División por asociación 

Hashing 

Asociación 

Hashing file organization 

Organización asociativa de archivos 

Hash-table overflow 

Desbordamiento de una tabla de asociación 

Head 

Cabeza 

Head-disk assemblies 

Dispositivos cabeza-disco 

Header 

Cabecera 

Heap file organization 

Organización de archivos en montículo 

Heterogeneous distributed database systems 

Sistemas distribuidos y heterogéneos de bases de datos 

Heterogeneous distributed databases 

Bases de datos distribuidas y heterogéneas 

Heuristic 

Heurística 

Hidden pointers 

Puntero oculto 

Hierarchical architecture 

Arquitectura jerárquica 

Hierarchical databases 

Bases de datos jerárquicas 

Hierarchical model 

Modelo jerárquico 

Hierarchy 

Jerarquía 

High availability 

Disponibilidad elevada 

Higher-level 

Nivel más alto 

Higher-level entity set 

Conjunto de entidades de nivel superior 

High-performance transaction systems 

Sistemas de transacciones de alto rendimiento 

High-performance transactions 

Transacción de alto rendimiento 

Histogram 

Histograma 

Histogram graph 

Grafo de histograma 

Holds on R 

Se cumple en R 

Home page 

Página inicial 

Homogeneous distributed database 

Base de datos distribuida homogénea 

Horizontal fragmentation 

Fragmentación horizontal 

Horizontal partitioning 

División horizontal 

Host 

Anfitrión 

Host Computer 

Computadora anfitriona 

Host language 

Lenguaje anfitrión 

Hot-spare configuration 

Configuración de relevo en caliente 

HTML (Hypertext markup language) 

Lenguaje de marcas de hipertexto 

HTTP (HyperText transfer protocol) 

Protocolo para transferencia de hipertexto 

Hybrid hash-join algorithm 

Algoritmo de reunión por asociación híbrida 

Hybrid merge-join algorithm 

Algoritmo híbrido de reunión por mezcla 

HyperCard 

HyperCard 

Hypercube interconnection 

Interconexión hipercubo 

Hypermedia systems 

Sistemas hipermedia 

Hypertext 

Hipertexto 
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Hypertext databases 

Bases de datos de hipertexto 

Hypertext markup language (HTML) 

Lenguaje de marcas de hipertexto 

HyperText transfer protocol (HTTP) 

Protocolo para transferencia de hipertexto 

I/O parallelism 

Paralelismo de E/S 

IBM Scientific Center 

Centro científico de IBM 

IBM T.J. Watson Research Center 

Centro de investigación T. J. Watson de IBM 

Idempotent 

Idempotente 

Identify 

Identificar 

Identifying relationship 

Relación de identificación 

IDL (Interface description language) 

Lenguaje de descripción de interfaces 

IEEE (Institute for electrical and electronical engineers) 

Instituto de ingenieros eléctricos y electrónicos 

Illustra database System 

Sistema de bases de datos Illustra 

Immediate 

Inmediata 

Immediate-modifications scherne 

Esquema de modificación inmediata 

Immediate-update technique 

Técnica de actualización inmediata 

Implement 

Implementar 

Implementation 

Implementación 

Implicit 

Implícito 

IMS (Information management System) 

Sistema gestor de información de IBM 

IMS Fast Path 

Fast Path de IMS 

IMS monitor 

Monitor IMS 

Inconsistent State 

Estado inconsistente 

Independent 

Independiente 

Independent parallelism 

Paralelismo independiente 

Index 

índice 

Index authorization 

Autorización de índice 

Index B + -tree 

índice del árbol B + 

Index entry 

Entrada del índice 

Index hashing 

Asociación de índice 

Index locking 

Bloqueo del índice 

Index record 

Registro del índice 

Index scans 

Exploraciones del índice 

Indexed nested-loop join 

Reunión en bucle anidado indexada 

Indexing documents 

Creación de índices de documentos 

Indexing spatial data 

Creación de índices de datos espaciales 

Index-locking technique 

Técnica de bloqueo de índice 

Index-sequential file 

Archivo secuencial indexado 

In-doubt transaction 

Transacción dudosa 

Inexpensive 

Bajo coste 

Infer 

Inferir 

Information management System (IMS) 

Sistema gestor de información de IBM 

Information retrieval 

Recuperación de la información 
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Ingres database System 

Sistema de bases de datos Ingres 


Inheritance 

Herencia 


In-memory pointers 

Punteros internos de memoria 


In-memory tree structure 

Estructura de árbol en memoria 


Inner (join) 

Interna (reunión) 


Insertion 

Inserción 


Instance 

Ejemplar 


Instance variable 

Variable de ejemplares 


Instantiation 

Ejemplar 


Institute for Electrical and Electronical Engineers (IEEE) 

Instituto de Ingenieros Eléctricos y Electrónicos 


Integrated Services digital network (ISDN) 

Red digital de servicios integrados (RDSI) 


Integrity 

Integridad 


Integrity constraints 

Restricciones de integridad 


Intention lock 

Bloqueo intencional 


Intention lock mode 

Modo de bloqueo intencional 


Intention-exclusive (IX) mode 

Modo intencional-exclusivo (IX) 


Intention-shared (IS) mode 

Modo intencional-compartido (IC) 


Interconnection network 

Red de interconexión 


Interface 

Interfaz (f.) 


Interface description language (IDL) 

Lenguaje de descripción de interfaces 


Interference 

Interferencia 


Intemal 

Interno 


International standards organization (ISO) 

Organización internacional de normalización 


Internet 

Internet 


Interoperation parallelism 

Paralelismo entre operaciones 


Interquery parallelism 

Paralelismo entre consultas 


Intersect operation 

Operación intersect 


Intersection 

Intersección 


Intersection operation 

Operación intersección 


Intersection rule 

Regla de la intersección 


Interval 

Intervalo 


Intraoperation parallelism 

Paralelismo en operaciones 


Intraquery parallelism 

Paralelismo en consultas 


Invalidation report 

Informe de invalidación 


Inverted Índex 

índice invertido 


Invoke a method 

Invocar un método 


ISDN (Integrated Services digital network) 

Red digital de servicios integrados (RDSI) 


ISO (International Standards Organization) 

Organización Internacional de Normalización 


Isochronous data 

Datos isócronos 


Isolation 

Aislamiento 


Iterator 

Iterador 


Java 

Java 
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JCL (Job control language) 

Lenguaje de control de trabajos 

Job control language (JCL) 

Lenguaje de control de trabajos 

Join 

Reunión 

Join dependencies 

Dependencias de reunión 

Join operation 

Operación join 

Join partitioning 

Reunión fraccionada 

Joint picture experts group (JPEG) 

Grupo conjunto de expertos en imágenes 

JPEG (Joint picture experts group) 

Grupo conjunto de expertos en imágenes 

Jukebox 

Cambiador automático 

k-d tree 

Árbol k-d 

k-d-B tree 

Árbol k-d-B 

Key 

Clave 

Keyword 

Palabra clave 

Keyword-based information retrieval 

Recuperación de información basada en palabras clave 

Kill 

Cancelar 

Knowledge-discovery systems 

Sistemas de descubrimiento del conocimiento 

Labeled graph precedence 

Precedencia de grafos etiquetados 

Labeled precedence graph 

Grafo de precedencia etiquetado 

LAN (Local-area network) 

Red de área local 

Large data Ítems recoverability 

Recuperabilidad de elementos de datos de gran tamaño 

Latch 

Pestillo 

Latency time 

Tiempo de latencia 

Lattice 

Retículo 

Layer 

Capa 

Least recently used (LRU) 

Utilizado menos recientemente 

Left outer join 

Reunión externa por la izquierda 

Left-deep join orders 

Órdenes de reunión en profundidad por la izquierda 

Leftmost-child tree 

Árbol hijo más a la izquierda 

Legacy systems 

Sistemas heredados 

Legal 

Legal 

Lexicographic ordering 

Orden lexicográfico 

Line 

Línea 

Linear hashing 

Asociación lineal 

Linear probing 

Ensayo lineal 

Linear scales 

Escalas lineales 

Linear scaleup 

Ampliabilidad lineal 

Linear search 

Búsqueda lineal 

Linear speedup 

Ganancia de velocidad lineal 

Link 

Enlace 

Link failure 

Fallo de enlace 

Linked list 

Lista enlazada 

Little-endian form 

Orden menos significativo 
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Load-balanced partition vector 

Vector de división con caiga equilibrada 

Load-balanced partitioning 

División con carga equilibrada 

Local autonomy 

Autonomía local 

Local transaction 

Transacción local 

Local transaction manager 

Gestor de transacciones locales 

Local wait-for graph 

Grafo de espera local 

Local-area network (LAN) 

Red de área local 

Local-read protocol 

Protocolo de lectura local 

Lock 

Bloqueo 

Lock conversions 

Conversiones de bloqueo 

Lock deescalation 

Liberación de bloqueos 

Lock point 

Punto de bloqueo 

Lock protocol 

Protocolo basado en el bloqueo 

Locking protocol 

Protocolo de bloqueo 

Log 

Registro histórico 

Log disk 

Disco de registro histórico 

Log forcé 

Forzar el registro histórico 

Log-based failure recovery 

Recuperación de fallos basada en el registro histórico 

Log-based file System 

Sistema de archivos basado en el registro histórico 

Logical dock 

Reloj lógico 

Logical connectives 

Conectivas lógicas 

Logical counter 

Contador lógico 

Logical error 

Error lógico 

Logical level 

Nivel lógico 

Logical logging 

Registro histórico lógico 

Logical object identifier 

Identificador lógico de objeto 

Logical operation 

Operación lógica 

Logical schema 

Esquema lógico 

Logical-design 

Diseño lógico 

Logically inrplied 

Implicadas lógicamente 

Log-record buffering 

Registro histórico con memoria intermedia 

Long fields 

Campos largos 

Long-distance Computer networks 

Redes informáticas de larga distancia 

Long-duration transaction 

Transacción de larga duración 

Lookup operation 

Operación lookup 

Lossless join 

Reunión sin pérdida 

Lossless-join decomposition 

Descomposición de reunión sin pérdida 

Lossy decomposition 

Descomposición con pérdida 

Lossy join 

Reunión con pérdida 

Lossy-join decomposition 

Descomposición de reunión con pérdida 

Lotus Notes 

Lotus Notes 

Lower-level 

Nivel más bajo 
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LRU (Least recently used) 

Utilizado menos recientemente 

LRU block-replacement scheme 

Esquema de sustitución de bloques LRU 

Magnetic tapes 

Cintas magnéticas 

Magnetic-disk storage 

Almacenamiento en discos magnéticos 

Main memory 

Memoria principal 

Main-memory database system 

Sistema de bases de datos en memoria principal 

Many to many mapping 

Correspondencia de varios a varios 

Many to one mapping 

Correspondencia de varios a uno 

Many-server, many-router model 

Modelo de varios servidores y varios encaminadores 

Many-server, single-router model 

Modelo de varios servidores y un solo encaminador 

Many-server, single-router routing 

Encaminamiento con varios servidores y un solo servidor 

Mapping 

Correspondencia 

Mapping cardinalities 

Correspondencia de cardinalidades 

Mart 

Puesto 

Massively parallel machine 

Máquina masivamente paralela 

Massively parallel system 

Sistema masivamente paralelo 

Materialization 

Materialización 

Materialize 

Materializar 

Materialized evaluation 

Evaluación materializada 

Materialized view 

Vista materializada 

Mean time to data loss 

Tiempo medio entre pérdidas de datos 

Mean time to failure 

Tiempo medio entre fallos 

Mean time to repair 

Tiempo medio de reparación 

Member (or child) 

Miembro (o hijo) 

Memory-style error-correcting-code organization (ECC) 

Organización de códigos de corrección de errores tipo memoria 

Merge 

Mezclar 

Merge-join algorithm 

Algoritmo de reunión por mezcla 

Mesh 

Trama 

Message 

Mensaje 

Metadata 

Metadatos 

Method 

Método 

Microsoft Access databases 

Bases de datos de Microsoft Access 

Mini-batch transaction 

Transacción por minilotes 

Minimum cost 

Coste mínimo 

Mirror disk 

Disco imagen 

Mirroring 

Creación de imágenes 

Missing 

Perdido 

Mixed fragmentation 

Fragmentación mixta 

Mobile Computer 

Computadora portátil 

Mobile databases 

Bases de datos portátiles 

Mobile support stations 

Estaciones de apoyo para computadoras portátiles 

Mobile-computing 

Informática portátil 
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Modem 

Módem 

Modification of databases 

Modificación de bases de datos 

Modular-stratification semantics 

Semántica de estratificación modular 

Module 

Módulo 

Monitor 

Observar 

Monotonic 

Monótona 

Monotonic function 

Función monótona 

Monotonic Systems 

Sistemas monótonos 

Most recently used (MRU) 

Utilizado más recientemente 

Most specific type 

Tipo más específico 

Motion picture experts group (MPEG) 

Grupo de expertos en películas 

MPEG (Motion picture experts group) 

Grupo de expertos en películas 

MPEG-1 standard 

Norma MPEG-1 

MPEG-2 standard 

Norma MPEG-2 

MRU (Most recently used) 

Utilizado más recientemente 

Multidatabase system 

Sistema con múltiples bases de datos 

Multidimensional data 

Datos multidimensionales 

Multilevel 

Multinivel 

Multilevel Índex 

índice multinivel 

Multilevel transaction 

Transacción multinivel 

Multimedia data formats 

Formatos de datos multimedia 

Multimedia databases 

Bases de datos multimedia 

Múltiple application-server processes 

Procesos del servidor para varias aplicaciones 

Múltiple granularity 

Granularidad múltiple 

Múltiple inheritance 

Herencia múltiple 

Múltiple transactions 

Varias transacciones 

Multiple-coordinator approach 

Enfoque de varios coordinadores 

Multiple-granularity locking protocol 

Protocolo de bloqueo de granularidad múltiple 

Multiple-key access 

Acceso multiclave 

Multiprogramming 

Multiprogramación 

Multiset 

Multiconjunto 

Multiset versions 

Versiones multiconjunto 

Multisystem applications 

Aplicaciones multisistema 

Multitasking 

Multitarea 

Multithreading 

Multienhebramiento 

Multiuser Systems 

Sistema multiusuario 

Multivalued 

Multivalorado 

Multivalued attributes 

Atributos multivalorados 

Multivalued augmentation rule 

Regla de la aumentatividad multivalorada 

Multivalued dependency 

Dependencia multivalorada 

Multivalued transitivity rule 

Regla de la transitividad multivalorada 

Multivalued unión rule 

Regla de la unión multivalorada 
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Multiversion 

Multiversion 

Multiversion concurrency-control scheme 

Esquema de control de concurrencia multiversion 

Multiversion database Systems 

Sistemas de bases de datos multiversion 

Multiversion timestamp-ordering scheme 

Esquema de ordenación por marcas temporales multiversion 

Multiversion two-phase locking protocol 

Protocolo de bloqueo de dos fases multiversion 

Naive user 

Usuario normal 

Ñame server 

Servidor de nombres 

Natural join 

Reunión natural 

Navigational model 

Modelo de navegación 

Nearest-neighbor query 

Consulta de vecino más próximo 

Nearness queries 

Consultas de proximidad 

Negative literal 

Literal negativo 

Nested relational 

Relacional anidado 

Nested relational model 

Modelo relacional anidado 

Nested transaction 

Transacción anidada 

Nested transactions 

Transacciones anidadas 

Nested-loop join 

Reunión en bucle anidado 

Nesting 

Anidamiento 

NetWork database 

Base de datos en red 

NetWork model 

Modelo de red 

NetWork partitioning 

División de la red 

NetWork transparency 

Transparencia de la red 

Network-level security 

Seguridad en el nivel de la red 

Nonacceptable termination State 

Estado de terminación no aceptable 

Nonatomic types 

Tipos no atómicos 

Nonclustering Índex 

índice sin agrupación 

Nonprocedural language 

Lenguaje no procedimental 

Nonrecoverable schedule 

Planificación no recuperable 

Nonserializable executions 

Ejecuciones no secuenciables 

Non-stop System 

Sistema ininterrumpido 

Nonvolatile random-access memory (nonvolatile RAM) 

Memoria no volátil de acceso aleatorio (RAM no volátil) 

Nonvolatile storage 

Almacenamiento no volátil 

Normal form 

Forma normal 

Normalization 

Normalización 

Not known 

No conocido 

NP-complete problems 

Problemas NP-completos 

Nuil 

Nulo 

Nuil attributes 

Atributos nulos 

Nuil valúes 

Valores nulos 

Number of block transfers from disk 

Número de transferencias de bloques de disco 

N- way merge 

Mezcla de n vías 

Object 

Objeto 
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Object classes 

Clases de objetos 

Object containment 

Continente de objetos 

Object database management group (ODMG) 

Grupo de gestión de bases de datos de objetos 

Object definition language (ODL) 

Lenguaje de definición de objetos 

Object identifier (OID) 

Identificador de objeto 

Object management architecture (OMA) 

Arquitectura para gestión de objetos 

Object management group (OMG) 

Grupo de gestión de objetos 

Object oriented programming (OOP) 

Programación orientada a objetos 

Object relational databases 

Bases de datos relaciónales orientadas a objetos 

Object relational models 

Modelos relaciónales orientados a objetos 

Object relational Systems 

Sistemas relaciónales orientados a objetos 

Object request broquer (ORB) 

Agente para peticiones de objetos 

Object SQL (OSQL) 

Object SQL 

Object-based data models 

Modelos lógicos basados en objetos 

Object-Oriented data rnodel 

Modelo de datos orientado a objetos 

Object-Oriented databases 

Bases de datos orientadas a objetos 

Object-Oriented model 

Modelo orientado a objetos 

Object-relational data models 

Modelos de datos relaciónales orientados a objetos 

Object-relational system 

Sistema relacional orientados a objetos 

Objects to files mapping 

Correspondencia de objetos a archivos 

Observable external writes 

Escrituras externas observables 

ODBC (Open database connectivity) 

Conectividad abierta de bases de datos 

ODL (Object definition language) 

Lenguaje de definición de objetos 

Office information Systems (OIS) 

Sistemas de información para oficinas 

Off-line 

Sin conexión 

Off-line storage 

Almacenamiento sin conexión 

Offset 

Desplazamiento 

OID (Object identifier) 

Identificador de objeto 

OIS (Office information systems) 

Sistemas de información para oficinas 

OLAP (On-line analytical processing) 

Procesamiento en conexión analítico 

OLTP (On-line transaction processing) 

Procesamiento en conexión de transacciones 

OMA (Objects management architecture) 

Arquitectura para gestión de objetos 

OMG (Objects management group) 

Grupo de gestión de objetos 

One to many mapping 

Correspondencia de uno a varios 

One to one mapping 

Correspondencia de uno a uno 

One-safe 

Uno seguro 

On-line 

Con conexión/Interactivo 

On-line analytical processing (OLAP) 

Procesamiento en conexión analítico 

On-line encyclopedias 

Enciclopedias interactivas 

On-line storage 

Almacenamiento en conexión 

On-line transaction processing (OLTP) 

Procesamiento en conexión de transacciones 

OOP (Object oriented programming) 

Programación orientada a objetos 
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Open database connectivity (ODBC) 

Conectividad abierta de bases de datos 

Open hashing 

Asociación abierta 

Operator tree 

Arbol de operadores 

Optical disks 

Discos ópticos 

Optical storage 

Almacenamiento óptico 

Or 

Disyunción 

Oracle 7 

Oracle 7 

ORB (Object request broquer) 

Agente para peticiones de objetos 

Ordered Índex 

índice ordenado 

Organize documents logically 

Organizar lógicamente los documentos 

OSQL (Object SQL) 

Object SQL 

Outer 

Externa 

Outer-join 

Reunión externa 

Output valúes 

Valores de salida 

Overflow block 

Bloque de desbordamiento 

Overflow buckets 

Cajones de desbordamiento 

Overflow chaining 

Cadena de desbordamiento 

Overlaps 

Solapa 

Overloading 

Sobrecarga 

Own 

Propietario 

Owner (or parent) 

Propietario (o padre) 

P+Q redundancy scheme 

Esquema de redundancia P+Q 

Page 

Página 

Page fault 

Fallo de página 

Page table 

Tabla de páginas 

Parallel architecture 

Arquitectura paralela 

Parallel database architectures 

Arquitecturas paralelas de bases de datos 

Parallel database System 

Sistema paralelo de bases de datos 

Parallel extemal sort-merge 

Mezcla-ordenación paralela externa 

Parallel join 

Reunión paralela 

Parallel join algorithm 

Algoritmo de reunión paralela 

Parallel sort 

Ordenación paralela 

Parallel system 

Sistema paralelos 

Parameter 

Parámetro 

Parent (or owner) 

Padre (o propietario) 

Pardal 

Parcial 

Partial key 

Clave parcial 

Partially connected network 

Red conectada parcialmente 

Partially dependent 

Dependiente parcialmente 

Participation 

Participación 

Partition («.) 

Partición 

Partition (v.) 

Dividir 
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Partition skew 

Sesgo de la división 

Partitioned hashing 

Asociación dividida 

Partitioned parallelism 

Paralelismo de particiones 

Pascal 

Pascal 

Pass 

Ciclo 

Password 

Contraseña 

Pathway 

Pathway 

Performance 

Rendimiento 

Performance benchmark 

Prueba de rendimiento 

Performance tuning 

Ajuste del rendimiento 

Performance-simulation model 

Modelo de simulación de rendimiento 

Persistence of objects 

Persistencia de los objetos 

Persistent extensions 

Extensiones persistentes 

Persistent pointer 

Puntero persistente 

Persistent programming language 

Lenguaje de programación persistente 

Phantom phenomenon 

Fenómeno fantasma 

Physical 

Físico 

Physical block 

Bloque físico 

Physical data model 

Modelo de datos físicos 

Physical level 

Nivel físico 

Physical log record 

Registro físico del registro histórico 

Physical logging 

Registro histórico físico 

Physical object identifier 

Identificador físico de objeto 

Physical schema 

Esquema físico 

Physical-design 

Diseño físico 

Pinned 

Clavado 

Pipeline 

Cauce 

Pipelined join 

Reunión encauzada 

Pipelined parallelism 

Paralelismo de encauzamiento 

Pipelining 

Encauzamiento 

PJNF (Project-join normal form) 

Forma normal de reunión por proyección (FNRP) 

Platter 

Plato 

Point 

Apuntar 

Point queries 

Consultas concretas 

Pointer 

Puntero 

Pointer fields 

Campo puntero 

Pointer swizzling 

Rescate de punteros 

Polling 

Encuestas 

Population 

Población 

Positive literal 

Literal positivo 

Possibility 

Posibilidad 

Postgres 

Postgres 


720 












































DICCIONARIO BILINGÜE 


PostScript 

PostScript 

PowerBuilder 

PowerBuilder 

PR quadtree 

Arbol cuadrático PR 

Precede 

Preceder 

Precedence graph 

Grafo de precedencia 

Precisión 

Precisión 

Preempt 

Expropiar 

Prefetching 

Preextracción 

Presentation facilities 

Utilidades para presentaciones 

Preserve equivalence 

Preservar la equivalencia 

Presume abort 

Suponer aborto 

Presume commit 

Suponer compromiso 

Price per TPS 

Precio por TPS 

Primary copy 

Copia principal 

Primary Índex 

índice primario 

Primary key 

Clave primaria 

Primary site 

Emplazamiento principal 

Primary storage 

Almacenamiento principal 

Prime 

Primo 

Prívate key 

Clave privada 

Privilege 

Privilegio 

Privilege list 

Lista de privilegios 

Probe 

Probar 

Probe input 

Entrada para probar 

Procedural language 

Lenguaje procedimental 

Process 

Proceso 

Processing 

Procesamiento 

Processing entity 

Entidad de procesamiento 

Process-per-client model 

Modelo de proceso por cliente 

Producer-driven pipelining 

Encauzamiento por los productores 

Program 

Programa 

Project 

Proyectar 

Project join 

Reunión por proyección 

Project operation 

Operación proyección 

Projection 

Proyección 

Project-join normal form (PJNF) 

Forma normal de reunión por proyección (FNRP) 

Prolog 

Prolog 

Pseudotransitivity rule 

Regla de la pseudotransitividad 

Public key 

Clave pública 

Public-key encryption 

Cifrado de clave pública 

Pulling 

Extracción 

Pushing 

Inserción 
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QBE (Query-by-example) 

Consulta mediante ejemplos 

QMF (Queries management facility) 

Recurso de gestión de consultas 

Quadtree 

Arbol cuadrático 

Quasi-serializability 

Cuasisecuencialidad 

Quel 

Quel 

Queries relations 

Relaciones de consultas 

Queries server Systems 

Sistemas servidores de consultas 

Query 

Consulta 

Query language 

Lenguaje de consultas 

Query management facility (QMF) 

Recurso de gestión de consultas 

Query optimization 

Optimización de consultas 

Query processing 

Procesamiento de consultas 

Query processor 

Procesador de consultas 

Query range 

Rango de las consultas 

Query-by-example (QBE) 

Consulta mediante ejemplos 

Query-evaluation algorithm 

Algoritmo para la evaluación de consultas 

Query-evaluation plan 

Plan de evaluación de la consulta 

Query-execution engine 

Motor de ejecución de consultas 

Query-execution plan 

Plan de ejecución de la consulta 

Query-server System 

Sistema servidor de consultas 

Queue 

Cola 

Queue manager 

Gestor de colas 

Queue System 

Sistema de colas 

Queue theory 

Teoría de colas 

Queueing systems 

Sistemas de colas 

Quicksort 

Ordenación rápida 

RAID (Redundant array of independent disks) 

Disposición redundante de discos independientes 

RAID levels 

Niveles de RAID 

Range of operation 

Operación range of 

Range partitioning 

División por rangos 

Range query 

Consulta de rangos 

Ráster 

Por líneas 

Reactionary standard 

Norma reaccionaria 

Read authorization 

Autorización de lectura 

Read commited 

Con compromiso de lectura 

Read phase 

Fase de lectura 

Read uncommited 

Sin compromiso de lectura 

Read-only 

Sólo de lectura 

Read-write head 

Cabeza de lectura y escritura 

Real graph 

Grafo real 

Real-time System 

Sistema de tiempo real 

Rebuild performance 

Rendimiento de reconstrucción 
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Recall 

Recuperación 

Reconfigure 

Volver a configurar 

Record 

Registro 

Record type Rlink 

Tipo de registro Renlace 

Record-based data models 

Modelos lógicos basados en registros 

Recover 

Recuperar 

Recoverability 

Recuperabilidad 

Recoverability schedule 

Recuperabilidad de planificaciones 

Recoverable schedules 

Planificaciones recuperables 

Recovery 

Recuperación 

Recovery algorithm 

Algoritmo de recuperación 

Recovery scheme 

Esquema de recuperación 

Recovery-management component 

Componente para la gestión de la recuperación 

Recursion 

Recursividad 

Recursive 

Recursivo 

Recursive partitioning 

División recursiva 

Redistribute 

Redistribuir 

Redo 

Rehacer 

Redo log record 

Registro rehacer del registro histórico 

Redo operation 

Operación redo 

Redo phase 

Fase rehacer 

Redo-list 

Lista-rehacer 

Redundancy 

Redundancia 

Redundant array of independent disks (RAID) 

Disposición redundante de discos independientes 

Redundant array of inexpensive disks systems 

Sistemas RAID 

Reed-Solomon codes 

Códigos Reed-Solomon 

Reference 

Referencia 

Reference privilege 

Privilegio de referencias 

Reference types 

Tipos de referencia 

Referencial-integrity constraints 

Restricciones de integridad referencial 

Referential integrity 

Integridad referencial 

Referential integrity constraint 

Restricción de integridad referencial 

Reflexivity rule 

Regla de la reflexividad 

Región quadtrees 

Arboles cuadráticos con regiones 

Región queries 

Consultas regionales 

Relation 

Relación 

Relation instance 

Ejemplar de relación 

Relation schema 

Esquema de la relación 

Relational algebra 

Algebra relacional 

Relational data models 

Modelos de datos relaciónales 

Relational databases 

Bases de datos relaciónales 

Relational model 

Modelo relacional 
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Relational operation 

Operación relacional 


Relational System 

Sistema relacional 


Relational-algebra expression 

Expresión del álgebra relacional 


Relationship 

Relación 


Relationship set 

Conjunto de relaciones 


Reliability 

Fiabilidad 


Remapping of bad sectors 

Reasignación de los sectores dañados 


Remóte backup site 

Nodo remoto copia de seguridad 


Remóte backup systems 

Sistemas remotos de copia de seguridad 


Remote-procedure-call (RPC) 

Llamada a procedimientos remotos 


Remote-procedure-call mechanism 

Mecanismo de llamadas a procedimientos remotos 


Rename 

Renombrar 


Rename operation 

Operación rename 


Renaming 

Renombramiento 


Reorganize 

Reorganizar 


Repeatable read 

Lectura repetible 


Repeating history 

Repetición de la historia 


Repetition of information 

Repetición de información 


Replace operation 

Operación replace 


Replication rule 

Regla de réplicas 


Report writers 

Diseñadores de informes 


Request 

Solicitud 


Requirement 

Requisito 


Resolution 

Resolución 


Resource authorization 

Autorización de recursos 


Resource manager 

Gestor de recursos 


Response 

Respuesta 


Restait recovery 

Recuperación al reiniciar 


Restriction 

Restricción 


Revoke statement 

Instrucción revoke 


Right outer join 

Reunión externa por la derecha 


Rigorous two-phase locking protocol 

Protocolo de bloqueo riguroso de dos fases 


Ring structure 

Estructura de anillo 


Robustness 

Robustez 


Role 

Papel 


Rollback (n.) 

Retroceso 


Rollback (v.) 

Retroceder 


Rollup 

Abstracción 


Rooted tree 

Árbol con raíz 


Rotational latency time 

Tiempo de latencia rotacional 


Round-robin 

Turno rotatorio 


Round-robin partitioning 

División por tumo rotatorio 
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Route 

Encaminar' 

Router 

Encaminador 

Routing 

Encaminamiento 

Row 

Fila 

RPC (Remote-procedure-call) 

Llamada a procedimientos remotos 

RTR monitors 

Monitores RTR 

R-tree 

Árbol R 

Rule 

Regla 

Run 

Secuencia 

SAA-SQL (System application architecture database interface) 

Interfaz de bases de datos para arquitecturas de aplicación a 
sistemas 

Safety 

Seguridad 

Saga 

Saga 

San José Research Center 

Laboratorio de Investigación de San José 

Satisfy 

Satisfacer 

Scaleup 

Ampliabilidad 

Scanning a relation 

Exploración de una relación 

SCSI (Small computer-system interconnect) 

Interconexión de pequeños sistemas informáticos 

Schedule 

Planificar 

Scheduling 

Planificación 

Schema 

Esquema 

Search key 

Clave de búsqueda 

Second normal form (2NF) 

Segunda forma normal (2FN) 

Secondary índex 

índice secundario 

Secondary site 

Nodo secundario 

Secondary storage 

Almacenamiento secundario 

Sector 

Sector 

Security specification 

Especificación de seguridad 

Seek time 

Tiempo de búsqueda 

Segmentation violation 

Violación de la segmentación 

Select 

Seleccionar 

Select operation 

Operación select 

Selection 

Selección 

Selectivity 

Selectividad 

Semantics of a program 

Semántica de un programa 

Semantics of a rule 

Semántica de una regla 

Semi join 

Semirreunión 

Semijoin strategy 

Estrategia de semirreunión 

Semistructured data 

Datos semiestructurados 

Sending a message 

Paso de mensaje 

Sentence 

Instrucción 

Sequential file 

Archivo secuencial 
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Sequential file organization índex 

índice de organización de archivos secuenciales 


Sequential sean 

Búsqueda secuencial 


Sequential-access storage 

Almacenamiento de acceso secuencial 


Serial 

Secuencial 


Serializability 

Secuencialidad 


Serializability order 

Orden de secuencialidad 


Server System 

Sistema servidor 


Service time 

Tiempo de servicio 


Set comparison 

Comparación de conjuntos 


Set difference 

Diferencia de conjuntos 


Set intersection 

Intersección de conjuntos 


Set membership 

Pertenencia al conjunto 


Set occurrence 

Aparición del conjunto 


Set operations 

Operaciones de conjuntos 


Set-difference operation 

Operación diferencia de conjuntos 


Set-top box Computer 

Microcomputadora 


SGML (Standard generalized markup language) 

Lenguaje normalizado de marcas generalizado 


Shadow copy 

Copia en la sombra 


Shadow page table 

Tabla de páginas sombra 


Shadow paging 

Paginación en la sombra 


Shadowing 

Creación de sombras 


Shared and intention-exclusive (SIX) mode 

Modo intencional-exclusivo y compartido (IXC) 


Shared lock 

Bloqueo compartido 


Shared memory 

Memoria compartida 


Shared mode locks 

Modo de bloqueo compartido 


Shared-disk architecture 

Arquitectura de disco compartido 


Shared-disk model 

Modelo de disco compartido 


Shared-disk system 

Sistema de disco compartido 


Shared-memory architecture 

Arquitectura de memoria compartida 


Shared-memory multiprocessor system 

Sistema multiprocesador de memoria compartida 


Shared-nothing architecture 

Arquitectura sin compartimiento 


Short-duration transaction 

Transacción de corta duración 


Shrinking phase 

Fase de decrecimiento 


Similar 

Semejante 


Similarity-based retrieval 

Recuperación basada en la semejanza 


Simula 

Simula 


Single relation schema 

Esquema de rotación única 


Single user system 

Sistema de usuario único 


Single valued 

Univalorados 


Single-server model 

Modelo de servidor único 


Site 

Nodo/Emplazamiento 


Skeleton tables 

Esqueletos de tablas 
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Skew («.) 

Sesgo 

Skew (v.) 

Sesgar 

Skew partitioning 

Sesgo de la división 

Slotted-page structure 

Estructura de páginas con ranuras 

Small computer-system interconnect (SCSI) 

Interconexión de pequeños sistemas informáticos 

Smalltalk 

Smalltalk 

Snapshot relation 

Relación instantánea 

Software swizzling 

Rescate software 

Sort-merge join 

Reunión por mezcla-ordenación 

Sort-merge-join algorithm 

Algoritmo de reunión por mezcla-ordenación 

Sound 

Correcto 

Sound rules 

Reglas correctas 

Span 

Duración 

Sparse Índex 

índice disperso 

Spatial databases 

Bases de datos espaciales 

Spatial join 

Reunión espacial 

Spatial queries 

Consultas espaciales 

Specialization 

Especialización 

Specification 

Especificación 

Specification of functional requirements 

Especificación de requisitos funcionales 

Specification of user requirements 

Especificación de requisitos del usuario 

Speedup 

Ganancia de velocidad 

Split 

Dividir 

SQL (Structured query language) 

Lenguaje estructurado de consultas 

SQL Access Group 

Grupo de acceso SQL 

SQL language reference privilege 

Privilegios de referencia del lenguaje SQL 

SQL language referencial integrity 

Integridad referencial en el lenguaje SQL 

SQL language standard 

Norma del lenguaje SQL 

Stable storage 

Almacenamiento estable 

Standard 

Norma 

Standard generalized markup language (SGML) 

Lenguaje normalizado de marcas generalizado 

Start 

Iniciar 

Startup 

Inicio 

Startup time 

Tiempo de inicio 

Starvation 

Inanición 

State of a workflow 

Estado de un flujo de trabajo 

Static hashing 

Asociación estática 

Statistical analyses 

Análisis estadísticos 

Statistical databases 

Bases de datos estadísticas 

Step 

Paso 

Stop words 

Palabras de parada 

Storage manager 

Gestor de almacenamiento 
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Stored 

Almacenado 

Strict two-phase locking protocol 

Protocolo de bloqueo estricto de dos fases 

String operations 

Operaciones de cadena 

Strong correctness 

Corrección fuerte 

Strong entity set 

Conjunto de entidades fuerte 

Strong types 

Tipos estrictos 

Structured query language (SQL) 

Lenguaje estructurado de consultas 

Subclass 

Subclase 

Sublinear scaleup 

Ampliabilidad sublineal 

Sublinear speedup 

Ganancia de velocidad sublineal 

Submit 

Remitir 

Subordínate entity 

Entidad subordinada 

Subquery 

Subconsulta 

Subschema 

Subesquema 

Subset dependency 

Dependencia de subconjunto 

Substitutability 

Posibilidad de sustitución 

Successful completion 

Terminación con éxito 

Sufficient conditions 

Condiciones suficientes 

Summary 

Resumen 

Superclass 

Superclase 

Superkey 

Superclave 

Superuser 

Superusuario 

Support 

Soporte 

Swap space 

Espacio de intercambio 

Swizzling 

Rescate 

Synonym 

Sinónimo 

Synthesize 

Sintetizar 

System application architecture database interface (SAA-SQL) 

Interfaz de bases de datos para arquitecturas de aplicación a 
sistemas 

System catalog 

Catálogo del sistema 

System dock 

Reloj del sistema 

System crash 

Caída del sistema 

System error 

Error del sistema 

System failure 

Fallo del sistema 

System R 

System R 

Table 

Tabla 

Tableau 

Tableau 

Tableau optimization 

Optimización con tableaux 

Tabular representation 

Representación tabular 

Tándem 

Tándem 

Tape jukebox 

Cambiador de cintas 

Tape storage 

Almacenamiento en cinta 
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Task 

Tarea 

Task flow 

Flujo de tareas 

Teleprocessing monitor 

Monitor de teleprocesamiento 

Témplate 

Plantilla 

Temporal database 

Base de datos temporal 

Temporal join 

Reunión temporal 

Temporal projection 

Proyección temporal 

Temporal query language 

Lenguaje de consultas temporales 

Temporal relation 

Relación temporal 

Temporal selection 

Selección temporal 

Teradata database machine 

Máquina de bases de datos de Teradata 

Terminal 

Terminal 

Terminated 

Terminado 

Termination States 

Estados de terminación 

Tertiary storage 

Almacenamiento terciario 

Testing for serializability 

Prueba de secuencialidad 

Text data 

Datos de texto 

Text-markup language 

Lenguaje de marcas de texto 

Theft of information 

Robo de información 

Theta (0) 

Zeta 

Third normal form (3NF) 

Tercera forma normal (3FN) 

Thomas’ write rule 

Regla de escritura de Thomas 

Three-pilase commit (3PC) protocol 

Protocolo de compromiso de tres fases (C3F) 

Throughput 

Productividad 

Ticket 

Billete 

Time stamp 

Marca temporal 

Time to completion 

Tiempo para finalizar 

Timeout lock 

Bloqueo con límite de tiempo 

Timeout scheme 

Esquema de tiempo límite 

Timestamp-based protocol 

Protocolo basado en la marca temporal 

Timestamp-ordering protocol 

Protocolo de ordenación por marcas temporales 

Timestamp-ordering scheme 

Esquema de ordenación por marcas temporales 

TLB (Translation lookaside buffer) 

Memoria intermedia con traducción anticipada 

To depend on 

Depender de 

Token ring 

Anillo con paso de testigo 

Top-down 

Descendente 

Topological sorting 

Ordenación topológica 

Toss-immediate strategy 

Estrategia de extracción inmediata 

Total 

Total 

TP (Transaction processing) 

Procesamiento de transacciones 

TPC (Transaction processing performance council) 

Consejo de rendimiento de procesamiento de transacciones 

TPS (Transactions per second) 

Transacciones por segundo 
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Track 

Pista 

Training set 

Conjunto de entrenamiento 

Transaction 

Transacción 

Transaction control 

Control de las transacciones 

Transaction coordinator 

Coordinador de transacciones 

Transaction failure 

Fallo en transacción 

Transaction management 

Gestión de transacciones 

Transaction processing (TP) 

Procesamiento de transacciones 

Transaction processing performance council (TPC) 

Consejo de rendimiento de procesamiento de transacciones 

Transaction rollback 

Retroceso de la transacción 

Transaction scaleup 

Ampliabilidad de transacciones 

Transaction server system 

Sistema servidor de transacciones 

Transaction time 

Tiempo de transacción 

Transaction workflow 

Flujo de trabajo de transacciones 

Transactional remóte procedure cali 

Llamada a procedimientos remotos de transacciones 

Transactional RPC interface 

Interfaz RPC para transacciones 

Transaction-management component 

Componente de gestión de transacciones 

Transactions per second (TPS) 

Transacciones por segundo 

Transaction-server systems 

Sistemas servidores de transacciones 

Transfer 

Transferir 

Transfer rate 

Velocidad de transferencia 

Transient 

Transitorio 

Transitive closure 

Cierre transitivo 

Transitive dependencies 

Dependencias transitivas 

Transitivity rule 

Regla de la transitividad 

Translation lookaside buffer (TLB) 

Memoria intermedia con traducción anticipada 

Tree protocol 

Protocolo de árbol 

Tree structure 

Estructura de árbol 

Tree-locking protocol 

Protocolo de bloqueo del árbol 

Tree-structure diagrams 

Diagramas de estructura de árbol 

Triangulation 

Teselación por triangulación 

Tries 

Tries 

Trigger («.) 

Disparador 

Trigger (v.) 

Disparar 

Triggering event 

Suceso disparador 

Trivial 

Trivial 

Trivial multivalued dependency 

Dependencia multivalorada trivial 

Tunable parameters 

Parámetros ajustables 

Tuning 

Ajuste 

Tupie 

Tupia 

Tupie relational calculus 

Cálculo relacional de tupias 

Tupie variable 

Variable tupia 
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Tupie-generating dependency 

Dependencia de generación de tupias 

Tuple-id 

Id-tupia 

Two-dimensional 

Bidimensional 

Two-level serializability 

Secuencialidad de dos niveles 

Two-phase commit (2PC) protocol 

Protocolo de compromiso de dos fases (C2F) 

Two-phase locking protocol 

Protocolo de bloqueo de dos fases 

Two-safe 

Dos seguro 

Two-very-safe 

Dos muy seguro 

Typical multiuser System 

Sistema multiusuario típico 

Typical single-user System 

Sistema monousuario típico 

Unary 

Unaria 

Uncommited data 

Datos no comprometidos 

Uncommited modification 

Modificación no comprometida 

Undo 

Deshacer 

Undo operation 

Operación undo 

Undo phase 

Fase deshacer 

Undo-list 

Lista-deshacer 

Unifying model 

Modelo de unificación 

Union 

Unión 

Union join 

Reunión de unión 

Union operation 

Operación unión 

Union rule 

Regla de la unión 

Unique 

Unico 

Unique identifier 

Identificador único 

Unique-role assumption 

Suposición de papel único 

Unit 

Unidad 

Universal resource locator (URL) 

Localizador universal de recursos 

Universel temps coordoné (UTC) 

Hora universal coordinada 

Unnesting 

Desanidamiento 

Unsafe 

No segura 

Unsafe workflow specification 

Especificación no segura del flujo de trabajo 

Unstructured documents 

Documentos no estructurados 

Unswizzle 

Devolver 

Update 

De actualización 

Update log record 

Registro de actualización del registro histórico 

Update mode 

Modo de actualización 

Update transaction 

Transacción de actualización 

Updates authorization 

Autorización de las actualizaciones 

URL (Universal resource locator) 

Localizador universal de recursos 

User 

Usuario 

User interfaces 

Interfaces de usuario 

User-coded functions 

Funciones codificadas por el usuario 
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User-defined design constraints 

Restricciones de diseño definidas por los usuarios 

User-guided data mining 

Recopilación de datos dirigida por el usuario 

UTC (Universel temps coordoné) 

Hora universal coordinada 

Utilization 

Utilización 

Valid time 

Tiempo válido 

Validation phase 

Fase de validación 

Validation protocol 

Protocolo de validación 

Validation scheme 

Esquema de validación 

Valué dependency 

Dependencia de valores 

Valué set 

Conjunto de valores 

Variable 

Variable 

Variable-length records 

Registros de longitud variable 

Vector partitioning 

Vector de división 

Versión vector 

Vector de versiones 

Vertex 

Nodo 

Vertical fragmentation 

Fragmentación vertical 

Video server 

Servidor de vídeo 

View 

Vista 

View equivalent 

Equivalente en cuanto a vistas 

View expansión 

Expansión de vistas 

View level 

Nivel de vistas 

View relation 

Relación de vistas 

View serializability 

Secuencialidad en cuanto a vistas 

View serializable 

Secuenciable en cuanto a vistas 

View-maintenance problem 

Problema del mantenimiento de las vistas 

Virtual ntemory 

Memoria virtual 

Virtual record 

Registro virtual 

Volatile storage 

Almacenamiento volátil 

Volume 

Volumen 

WAIS (Wide area information system) 

Sistema de información de área amplia 

Wait 

Esperar 

Wait-die scheme 

Esquema esperar-morir 

Wait-for graph 

Grafo de espera 

WAL (Write-ahead logging) 

Registro histórico de escritura anticipada 

WAN (Wide-area network) 

Red de área amplia 

Weak consistency 

Consistencia débil 

Weak entity set 

Conjunto de entidades débil 

Web crawler 

Web crawler 

Web server 

Servidor Web 

Where operation 

Operación where 

Wide area information system (WAIS) 

Sistema de información de área amplia 

Wide-area network (WAN) 

Red de área amplia 
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Workflow 

Flujo de trabajo 

Workflow management 

Gestión del flujo de trabajo 

Workflow Management Coalition 

Coalición para la gestión de flujos de trabajo 

Workflow specification 

Especificación del flujo de trabajo 

Workflow-management system 

Sistema gestor de flujos de trabajo 

World Wide Web (WWW) 

World Wide Web 

WORM (Write-once, read-many) 

Escritura única y lectura múltiple 

WORM jukebox 

Cambiador de discos WORM 

Wound-wait scheme 

Esquema herir-esperar 

Write phase 

Fase de escritura 

Write-ahead logging (WAL) 

Registro histórico de escritura anticipada 

Write-once, read-many (WORM) 

Escritura única y lectura múltiple 

Wrong 

Erróneo 

WWW (World Wide Web) 

World Wide Web 

X/open distributed transaction processing standard 

Norma para el procesamiento de transacciones distribuidas 
X/Open 

XML (Extensible Markup Language) 

Lenguaje de marcas extensible 
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Español 

Inglés 

1FN (Primera forma normal) 

First normal form (INF) 

2FN (Segunda forma normal) 

Second normal form (2NF) 

3FN (Tercera forma normal) 

Third normal form (3NF) 

4FN (Cuarta forma normal) 

Fourth normal form (4NF) 

ABD (Administrador de la base de datos) 

Database administrator (DBA) 

Abortada (transacción) 

Aborted 

Abstracción 

Rollup 

Abstracción de datos 

Data abstraction 

Abstracto 

Abstract 

Acceso multiclave 

Multiple-key access 

Acíclico 

Acyclic 

Administrador de bases de datos (ABD) 

Database administrator (DBA) 

Advertencia 

Alerting 

Agente para peticiones de objetos 

Object request broquer (ORB) 

Agregación 

Aggregation 

Agrupación 

Cluster («.) 

Agrupación 

Grouping 

Agrupamiento 

Clustering 

Agrupar 

Cluster (v.) 

Aislamiento 

Isolation 

Ajuste 

Tuning 

Ajuste del rendimiento 

Performance tuning 

Algebra relacional 

Relational algebra 

Algoritmo de control de concurrencia en árboles B + 

B + -tree concurrency-control algorithm 

Algoritmo de detección de interbloqueos completamente 
distribuido 

Fully distributed deadlock-detection algorithm 

Algoritmo de elección 

Election algorithm 

Algoritmo de mezcla-ordenación extema 

Extemal merge-sort algorithm 

Algoritmo de recuperación 

Recovery algorithm 

Algoritmo de reunión paralela 

Parallel join algorithm 

Algoritmo de reunión por asociación híbrida 

Hybrid hash-join algorithm 

Algoritmo de reunión por mezcla 

Merge-join algorithm 

Algoritmo de reunión por mezcla-ordenación 

Sort-merge-join algorithm 

Algoritmo del ascensor 

Elevator algorithm 

Algoritmo híbrido de reunión por mezcla 

Flybrid merge-join algorithm 

Algoritmo luchador 

Bully algorithm 

Algoritmo para control de la concurrencia para los árboles B + 

Concurrency control B + -trees algorithm 

Algoritmo para el tratamiento de interbloqueos 

Deadlock-handling algorithm 

Algoritmo para la detección de interbloqueos 

Deadlock-detection algorithm 

Algoritmo para la evaluación de consultas 

Query-evaluation algorithm 
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Algoritmos de control de concurrencia en árboles B + B + -tree concurrency control algorithms 


Algoritmos de evaluación de consultas 

Evaluation algorithms queries 

Alias 

Alias 

Almacén de datos 

Data warehouse 

Almacenado 

Stored 

Almacenamiento de acceso directo 

Direct-access storage 

Almacenamiento de acceso secuencial 

Sequential-access storage 

Almacenamiento de datos 

Data storage 

Almacenamiento de datos en caché 

Data caching 

Almacenamiento en cinta 

Tape storage 

Almacenamiento en conexión 

On-line storage 

Almacenamiento en disco 

Disk storage 

Almacenamiento en discos magnéticos 

Magnetic-disk storage 

Almacenamiento estable 

Stable storage 

Almacenamiento no volátil 

Nonvolatile storage 

Almacenamiento óptico 

Optical storage 

Almacenamiento principal 

Primary storage 

Almacenamiento secundario 

Secondary storage 

Almacenamiento sin conexión 

Off-line storage 

Almacenamiento terciario 

Tertiary storage 

Almacenamiento volátil 

Volatile storage 

Ampliabilidad 

Scaleup 

Ampliabilidad de transacciones 

Transaction scaleup 

Ampliabilidad lineal 

Linear scaleup 

Ampliabilidad por lotes 

Batch scaleup 

Ampliabilidad sublineal 

Sublinear scaleup 

Análisis estadísticos 

Statistical analyses 

Anfitrión 

Host 

Anidamiento 

Nesting 

Anillo con paso de testigo 

Token ring 

Any 

Any 

Aparición del conjunto 

Set occurrence 

Aplicación informática 

Computer application 

Aplicaciones de bases de datos 

Database applications 

Aplicaciones multisistema 

Multisystem applications 

Apuntar 

Point 

Árbol B + 

B + -tree 

Árbol con raíz 

Rooted tree 

Árbol cuadrático 

Quadtree 

Árbol cuadrático PR 

PR quadtree 

Árbol de clasificación 

Classification tree 

Árbol de la base de datos 

Database tree 
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Árbol de operadores 

Operator tree 

Árbol hijo más a la izquierda 

Leftmost-child tree 

Árbol k-d 

k-d tree 

Árbol k-d-B 

k-d-B tree 

Árbol R 

R-tree 

Árboles B enlazados 

B-link trees 

Árboles binarios 

Binary trees 

Árboles cuadráticos con regiones 

Región quadtrees 

Arco 

Edge 

Archivo 

File 

Archivo de datos 

Data archival 

Archivo en retícula 

Grid file 

Archivo secuencial 

Sequential file 

Archivo secuencial indexado 

Index-sequential file 

Arpanet 

Arpanet 

Arquitectura común de agente para peticiones de objetos 

Common object request broker architecture (CORBA) 

Arquitectura de disco compartido 

Shared-disk architecture 

Arquitectura de memoria compartida 

Shared-memory architecture 

Arquitectura jerárquica 

Hierarchical architecture 

Arquitectura para gestión de objetos 

Object management architecture (OMA) 

Arquitectura paralela 

Parallel architecture 

Arquitectura sin compartimiento 

Shared-nothing architecture 

Arquitecturas distribuidas de memoria virtual 

Distributed virtual-memory architecture 

Arquitecturas paralelas de bases de datos 

Parallel database architectures 

Array 

Array 

Array en retícula 

Grid array 

Ascendente 

Bottom-up 

Ascending order 

Ascending order 

Aserto 

Assertion 

Asignación 

Assignment 

Asociación 

Hashing 

Asociación abierta 

Open hashing 

Asociación cerrada 

Closed hashing 

Asociación de funciones 

Function hashing 

Asociación de índice 

Index hashing 

Asociación dinámica 

Dynamic hashing 

Asociación dividida 

Partitioned hashing 

Asociación estática 

Static hashing 

Asociación extensible 

Extendable hashing 

Asociación lineal 

Linear hashing 

Asociar 

Hash 

Asumir 

Assume 
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Atasco de cajones 

Bucket skew 

Atomicidad 

Atomicity 

Atomicidad ante fallos 

Failure- atomic ity 

Atómico 

Atomic 

Atomo 

Atom 

Atributo 

Attribute 

Atributos compuestos 

Composite attributes 

Atributos derivados 

Derived attributes 

Atributos descriptivos 

Descriptive attributes 

Atributos multivalorados 

Multivalued attributes 

Atributos nulos 

Nuil attributes 

Autonomía local 

Local autonomy 

Autorización 

Authorization 

Autorización de índice 

Index authorization 

Autorización de las actualizaciones 

Updates authorization 

Autorización de lectura 

Read authorization 

Autorización de recursos 

Resource authorization 

Axioma 

Axiorn 

Axiomas de Armstrong 

Armstrong’s axioms 

Bajo coste 

Inexpensive 

Base 

Base 

Base de datos (BD) 

Database (DB) 

Base de datos distribuida homogénea 

Homogeneous distributed database 

Base de datos en forma normal de dominios y claves (FNDC) 

Domain-key normal forrn (DKNF) database 

Base de datos en red 

Network database 

Base de datos temporal 

Temporal database 

Bases de datos centralizadas 

Centralized databases 

Bases de datos CODASYL DBTG 1991 

CODASYL DBTG 1991 databases 

Bases de datos de hipertexto 

Hypertext databases 

Bases de datos de Microsoft Access 

Microsoft Access databases 

Bases de datos distribuidas y heterogéneas 

Heterogeneous distributed databases 

Bases de datos espaciales 

Spatial databases 

Bases de datos estadísticas 

Statistical databases 

Bases de datos geográficas 

Geographic databases 

Bases de datos jerárquicas 

Hierarchical databases 

Bases de datos multimedia 

Multimedia databases 

Bases de datos orientadas a objetos 

Object-Oriented databases 

Bases de datos para diseño 

Design databases 

Bases de datos para diseño asistido por computadora (CAD) 

Computer-aided-design (CAD) databases 

Bases de datos portátiles 

Mobile databases 

Bases de datos relaciónales 

Relational databases 

Bases de datos relaciónales orientadas a objetos 

Object relational databases 
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Basura 

Garbage 

BD (Base de datos) 

Database (DB) 

Bidimensional 

Two-dimensional 

Billete 

Ticket 

Binario 

Binary 

Bloque 

Block 

Bloque de desbordamiento 

Overflow block 

Bloque de memoria intermedia 

Buffer block 

Bloque físico 

Physical block 

Bloqueo 

Blocking/Lock 

Bloqueo compartido 

Shared lock 

Bloqueo con límite de tiempo 

Timeout lock 

Bloqueo del índice 

Index locking 

Bloqueo en modo exclusivo 

Exclusive mode lock 

Bloqueo exclusivo 

Exclusive lock 

Bloqueo intencional 

Intention lock 

Borrado 

Deletion 

Borrar 

Delete 

Brazo del disco 

Disk arm 

Bus 

Bus 

Búsqueda binaria 

Binary search 

Búsqueda lineal 

Linear search 

Búsqueda secuencial 

Sequential sean 

C2F (Protocolo de compromiso de dos fases) 

Two-phase commit (2PC) protocol 

C3F (Protocolo de compromiso de tres fases) 

Three-phase commit (3PC) protocol 

Cabecera 

Header 

Cabecera de archivo 

File header 

Cabeza 

Head 

Cabeza de lectura y escritura 

Read-write head 

Caché 

Cache 

CAD (Bases de datos para diseño asistido por computadora) 

Computer-aided-design (CAD) databases 

CAD de bases de datos 

Database CAD 

Cadena de desbordamiento 

Overflow chaining 

Caída 

Crash 

Caída del sistema 

System crash 

Caja 

Box 

Caja de condición 

Condition box 

Caja límite 

Bounding box 

Cajón 

Bucket 

Cajones de desbordamiento 

Overflow buckets 

Cálculo relacional de dominios 

Domain relational calculus 

Cálculo relacional de tupias 

Tupie relational calculus 
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Cambiador automático 

Jukebox 

Cambiador de cintas 

Tape jukebox 

Cambiador de discos WORM 

WORM jukebox 

Cambio de contexto 

Context switch 

Caminos de acceso 

Access paths 

Campo puntero 

Pointer fields 

Campos largos 

Long fields 

Cancelar 

Kill 

Capa 

Layer 

Catálogo del sistema 

System catalog 

Cauce 

Pipeline 

Celda 

Cell 

Centro científico de IBM 

IBM Scientific Center 

Centro de investigación de Almadén 

Almadén Research Center 

Centro de investigación T. J. Watson de IBM 

IBM T. J. Watson Research Center 

Ciclo 

Pass 

Ciclos falsos 

False cycles 

Cierre 

Closure 

Cierre transitivo 

Transitive closure 

Cifrado 

Encryption 

Cifrado de clave pública 

Public-key encryption 

Cifrar 

Encrypt 

Cintas magnéticas 

Magnetic tapes 

Clase 

Class 

Clases de objetos 

Object classes 

Clasificación 

Classification 

Clavado 

Pinned 

Clave 

Key 

Clave candidata 

Candidate key 

Clave de búsqueda 

Search key 

Clave de cifrado 

Encryption key 

Clave externa 

Foreign key 

Clave parcial 

Partial key 

Clave primaria 

Primary key 

Clave privada 

Prívate key 

Clave pública 

Public key 

Cliente-servidor 

Client-server 

Coalición para la gestión de flujos de trabajo 

Workflow Management Coalition 

Código intermedio 

Byte code 

Códigos Reed-Solomon 

Reed-Solomon codes 

Coherencia de caché 

Cache coherency 

Cola 

Queue 
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Colgante 

Dangling 

Combinar 

Combine 

Comparación 

Comparison 

Comparación de conjuntos 

Set comparison 

Compatible 

Compatible 

Complejo 

Complex 

Completo 

Complete 

Componente ( m.) 

Component 

Componente de control de concurrencia 

Concurrency-control component 

Componente de gestión de transacciones 

Transaction-management component 

Componente para la gestión de la recuperación 

Recovery-management component 

Componentes de concurrencia 

Concurrency components 

Composición de operaciones relaciónales 

Composition of relational operations 

Comprobación de suma 

Checksum 

Comprometer 

Commit 

Comprometido 

Commited 

Compromiso 

Commitment 

Compuesto 

Composite 

Computadora anfitriona 

Host Computer 

Computadora portátil 

Mobile Computer 

Comunicar 

Cali back 

Con compromiso de lectura 

Read commited 

Con conexión 

On-line 

Conceptual 

Conceptual 

Concesión 

Grant 

Concesión de bloqueos 

Granting of locks 

Concesión de privilegios 

Granting of privileges 

Concreción 

Drill down 

Condiciones suficientes 

Sufficient conditions 

Conectivas lógicas 

Logical connectives 

Conectividad abierta de bases de datos 

Open database connectivity (ODBC) 

Conexión continua 

Continuous connection 

Confianza 

Confidence 

Configuración de relevo en caliente 

Hot-spare configuration 

Confluente 

Confluent 

Conjunto DBTG 

DBTG set 

Conjunto de entidades 

Entity set 

Conjunto de entidades de nivel superior 

Higher-level entity set 

Conjunto de entidades débil 

Weak entity set 

Conjunto de entidades fuerte 

Strong entity set 

Conjunto de entrenamiento 

Training set 

Conjunto de relaciones 

Relationship set 
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Conjunto de valores 

Valué set 

Consejo de rendimiento de procesamiento de transacciones 

Transaction processing performance council (TPC) 

Conservación de las dependencias 

Dependency preservation 

Consistencia 

Consistency 

Consistencia de grado dos 

Degree-two consistency 

Consistencia de los datos 

Data consistency 

Consistencia débil 

Weak consistency 

Constructora 

Constructor 

Construir 

Build 

Consulta 

Query 

Consulta de rangos 

Range query 

Consulta de vecino más próximo 

Nearest-neighbor query 

Consulta mediante ejemplos 

Query-by-example (QBE) 

Consultas con tipos complejos 

Complex queries types 

Consultas concretas 

Point queries 

Consultas de ayuda para las decisiones 

Decision-support queries 

Consultas de proximidad 

Neamess queries 

Consultas espaciales 

Spatial queries 

Consultas regionales 

Región queries 

Contador lógico 

Logical counter 

Contaminación de los datos 

Data pollution 

Contiene 

Contains 

Continente de objetos 

Object containment 

Contraseña 

Password 

Control de la concurrencia 

Concurrency control 

Control de las transacciones 

Transaction control 

Controlador de disco 

Disk controller 

Conversiones de bloqueo 

Lock conversions 

Coordinador copia de seguridad 

Backup coordinator 

Coordinador de transacciones 

Transaction coordinator 

Copia en la sombra 

Shadow copy 

Copia principal 

Primary copy 

Corrección fuerte 

Strong correctness 

Correcto 

Sound 

Correspondencia 

Mapping 

Correspondencia de cardinalidades 

Mapping cardinalities 

Correspondencia de objetos a archivos 

Objects to files mapping 

Correspondencia de uno a uno 

One to one mapping 

Correspondencia de uno a varios 

One to many mapping 

Correspondencia de varios a uno 

Many to one mapping 

Correspondencia de varios a varios 

Many to many mapping 

Coste de la evaluación paralela de operaciones 

Cost of parallel evaluation of operations 
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Coste de la transmisión de datos 

Data transmission cost 

Coste mínimo 

Minimum cost 

Creación de imágenes 

Mirroring 

Creación de índices de datos espaciales 

Indexing spatial data 

Creación de índices de documentos 

Indexing documents 

Creación de sombras 

Shadowing 

Cuarta forma normal (4FN) 

Fourth normal form (4NF) 

Cuasisecuencialidad 

Quasi-serializability 

Cuello de botella 

Bottleneck 

Cuerpo 

Body 

Datalog 

Datalog 

Datos abstractos 

Abstract data 

Datos de medios continuos 

Continuous-media data 

Datos de sonido y de vídeo 

Audio and video data 

Datos de texto 

Text data 

Datos distribuidos 

Distributed data 

Datos geográficos 

Geographic data 

Datos gráficos 

Graphical data 

Datos isócronos 

Isochronous data 

Datos multidimensionales 

Multidimensional data 

Datos no comprometidos 

Uncommited data 

Datos semiestructurados 

Semistructured data 

De actualización 

Update 

De manera contigua 

Contiguously 

Definición de las estructuras de datos 

Data structure definition 

Definido por atributo 

Attribute-defined 

Denominación de datos 

Data naming 

Dependencia de existencia 

Existence dependency 

Dependencia de generación de igualdad 

Equality-generating dependency 

Dependencia de generación de tupias 

Tuple-generating dependency 

Dependencia de subconjunto 

Subset dependency 

Dependencia de valores 

Valué dependency 

Dependencia funcional 

Functional dependency 

Dependencia multivalorada 

Multivalued dependency 

Dependencia multivalorada trivial 

Trivial multivalued dependency 

Dependencias de existencia 

Existence dependencies 

Dependencias de reunión 

Join dependencies 

Dependencias funcionales 

Functional dependencies 

Dependencias transitivas 

Transitive dependencies 

Depender de 

To depend on 

Dependiente parcialmente 

Partially dependent 

Desacoplada 

Decoupled 
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Desanidamiento 

Unnesting 

Desbordamiento de cajones 

Bucket overflow 

Desbordamiento de una tabla de asociación 

Hash-table overflow 

Descendente 

Top-down 

Descifrar 

Decrypt 

Descomponer 

Decompose 

Descomposición 

Decomposition 

Descomposición con conservación de las dependencias 

Dependency-preserving decomposition 

Descomposición con pérdida 

Lossy decomposition 

Descomposición de reunión con pérdida 

Lossy-join decomposition 

Descomposición de reunión sin pérdida 

Lossless-join decomposition 

Descomposición que conserva las dependencias 

Dependency-preserving decomposition 

Descubrimiento de reglas de asociación 

Association rules discovery 

Deshacer 

Undo 

Desmarcar 

Checkout 

Desplazamiento 

Offset 

Desreferenciación 

Dereferencing 

Desreferenciar 

Dereference 

Destructor 

Destructor 

Detección de fallos 

Failure detection 

Detección de interbloqueos 

Deadlock detection 

Devolución 

Deswizzling 

Devolver 

Unswizzle 

Diagrama de estructura de datos 

Data-structure diagram 

Diagrama de la estructura de datos 

Data structure diagram 

Diagrama entidad-relación 

Entity-relationship diagram 

Diagrama E-R 

E-R diagram 

Diagramas de estructura de árbol 

Tree-structure diagrams 

Diccionario de datos 

Data dictionary 

Diferencia de conjuntos 

Set difference 

Diferida 

Deferred 

Difusión de datos 

Data broadcast 

Difuso 

Fuzzy 

Dinámico 

Dynamic 

Dirección de entrega 

Forwarding address 

Directorio de datos 

Data directory 

Disco de cabezas fijas 

Fixed-head disk 

Disco de registro histórico 

Log disk 

Disco imagen 

Mirror disk 

Disco rígido 

Hard disk 

Discos imagen 

Disk mirroring 

Discos ópticos 

Optical disks 
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Discriminante 

Discriminator 

Diseñadores de informes 

Report writers 

Diseño asistido por computadora 

Computed-aided design (CAD) 

Diseño conceptual 

Conceptual-design 

Diseño de bases de datos 

Database design 

Diseño físico 

Physical-design 

Diseño lógico 

Logical-design 

Disparador 

Trigger («.) 

Disparar 

Trigger (v.) 

Disponibilidad elevada 

High availability 

Disposición redundante de discos independientes 

Redundant array of independent disks (RAID) 

Dispositivos cabeza-disco 

Head-disk assemblies 

Disquetes 

Floppy disks 

Distribución a nivel de bloque 

Block-level striping 

Distribución a nivel de bit 

Bit-level striping 

Distribución de datos 

Data striping 

Disyunción 

Or 

Dividir 

Paitition/ Split 

División 

División 

División con carga equilibrada 

Load-balanced partitioning 

División de datos 

Data partitioning 

División de la red 

NetWork partitioning 

División horizontal 

Horizontal partitioning 

División por asociación 

Hash partitioning 

División por rangos 

Range partitioning 

División por turno rotatorio 

Round-robin partitioning 

División recursiva 

Recursive partitioning 

Documento 

Document 

Documentos activos 

Active documents 

Documentos no estructurados 

Unstructured documents 

Dominio 

Domain 

Dominio atómico 

Atomic domain 

Dos muy seguro 

Two-very-safe 

Dos seguro 

Two-safe 

Durabilidad 

Durability 

Duración 

Span 

Eficiente 

Efficient 

Ejecución de los flujos de trabajo 

Execution of workflows 

Ejecuciones no secuenciables 

Nonserializable executions 

Ejemplar 

Instance 

Ejemplar básico 

Ground instantation 

Ejemplar básico de una regla 

Ground instantiation of a rule 
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Ejemplar de la base de datos 

Database instance 

Ejemplar de relación 

Relation instance 

Elección 

Election 

Elemento ejemplo 

Example element 

Eliminación de duplicados 

Duplicate elimination 

Eliminar 

Drop 

Emplazamiento principal 

Primary site 

Encaminador 

Router 

Encaminamiento 

Routing 

Encaminamiento con varios servidores y un solo servidor 

Many-server, single-router routing 

Encaminar 

Route 

Encapsulamiento 

Encapsulating 

Encapsulamiento de datos 

Data encapsulating 

Encauzamiento 

Pipelining 

Encauzamiento bajo demanda 

Demand-driven pipelining 

Encauzamiento por los productores 

Producer-driven pipelining 

Enciclopedias interactivas 

On-line encyclopedias 

Encuestas 

Polling 

Enfoque centralizado 

Centralized approach 

Enfoque de varios coordinadores 

Multiple-coordinator approach 

Enlace 

Link 

Ensayo lineal 

Linear probing 

Entidad 

Entity 

Entidad de procesamiento 

Processing entity 

Entidad dominante 

Dominant entity 

Entidad subordinada 

Subordínate entity 

Entorno distribuido 

Distributed environment 

Entrada del índice 

Index entry 

Entrada para construir 

Build input 

Entrada para probar 

Probe input 

Equilibrado 

Balanced 

Equirre unión 

Equi-join 

Equivalente en cuanto a conflictos 

Conflict equivalent 

Equivalente en cuanto a vistas 

View equivalent 

Erróneo 

Wrong 

Error del sistema 

System error 

Error lógico 

Logical error 

Escalas lineales 

Linear scales 

Escritura única y lectura múltiple 

Write-once, read-many (WORM) 

Escrituras a ciegas 

Blind writes 

Escrituras externas observables 

Observable extemal writes 

Espacio de intercambio 

Swap space 
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Especialización 

Specialization 

Especificación 

Specification 

Especificación de requisitos del usuario 

Specification of user requirements 

Especificación de requisitos funcionales 

Specification of functional requirements 

Especificación de seguridad 

Security specification 

Especificación de una norma para las bases de datos 

Database-standard specification 

Especificación del flujo de trabajo 

Workflow specification 

Especificación no segura del flujo de trabajo 

Unsafe workflow specification 

Esperar 

Wait 

Esqueletos de tablas 

Skeleton tables 

Esquema 

S chema 

Esquema de bases de datos entidad-relación 

Entity-relationship database schema 

Esquema de control de concurrencia nrultiversión 

Multiversión concurrency-control scheme 

Esquema de detección y recuperación de interbloqueos 

Deadlock-detention and deadlock-recovery scheme 

Esquema de la base de datos 

Database schema 

Esquema de la empresa 

Enterprise schema 

Esquema de la relación 

Relation schema 

Esquema de modificación inmediata 

Immediate-modifications scheme 

Esquema de ordenación por marcas temporales 

Timestamp-ordering scheme 

Esquema de ordenación por marcas temporales multiversión 

Multiversión timestamp-ordering scheme 

Esquema de recuperación 

Recovery scheme 

Esquema de redundancia P+Q 

P+Q redundancy scheme 

Esquema de rotación única 

Single relation schema 

Esquema de sustitución de bloques LRU 

LRU block-replacement scheme 

Esquema de tiempo límite 

Timeout scheme 

Esquema de validación 

Validation scheme 

Esquema esperar-morir 

Wait-die scheme 

Esquema físico 

Physical schema 

Esquema herir-esperar 

Wound-wait scheme 

Esquema lógico 

Logical schema 

Esquemas de control de concurrencia 

Concurrency-control schemes 

Esquemas de volcado difuso 

Fuzzy dump schemes 

Estabilidad del cursor 

Cursor stability 

Estaciones de apoyo para computadoras portátiles 

Mobile support stations 

Estado de terminación abortado 

Aborted termination State 

Estado de terminación aceptable 

Acceptable termination State 

Estado de terminación aceptable abortado 

Aborted acceptable termination State 

Estado de terminación aceptable comprometido 

Committed acceptable termination State 

Estado de terminación comprometido 

Commited termination State 

Estado de terminación no aceptable 

Nonacceptable termination State 

Estado de un flujo de trabajo 

State of a workflow 

Estado inconsistente 

Inconsistent State 
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Estados de ejecución 

Execution States 

Estados de terminación 

Termination States 

Estimar 

Estimate 

Estrategia de extracción inmediata 

Toss-immediate strategy 

Estrategia de semirreunión 

Semijoin strategy 

Estrategia para la sustitución de bloques 

Block-replacement strategy 

Estructura de anillo 

Ring stmcture 

Estructura de árbol 

Tree structure 

Estructura de árbol en memoria 

In-memory tree structure 

Estructura de archivos 

File structure 

Estructura de índice de árbol B + 

B + -tree Índex structure 

Estructura de páginas con ranuras 

Slotted-page structure 

Ethernet 

Ethernet 

Evaluación materializada 

Materialized evaluation 

Evento 

Event 

Evitación 

Avoidance 

Expansión de vistas 

View expansión 

Explícito 

Explicit 

Exploración 

Browsing 

Exploración de una relación 

Scanning a relation 

Exploraciones del índice 

Index scans 

Explorador de archivo 

File sean 

Expresión del álgebra relacional 

Relational-algebra expression 

Expropiar 

Preempt 

Extensión 

Extensión 

Extensiones de clases 

Class extents 

Extensiones persistentes 

Persistent extensions 

Externa (reunión) 

Outer 

Externo 

External 

Extracción 

Pulling 

Factor de escape 

Fudge factor 

Fallo de disco 

Disk failure 

Fallo de enlace 

Link failure 

Fallo de página 

Page fault 

Fallo del sistema 

System failure 

Fallo en la transferencia de datos 

Data transfer failure 

Fallo en transacción 

Transaction failure 

Fase de crecimiento 

Growing phase 

Fase de decrecimiento 

Shrinking phase 

Fase de escritura 

Write phase 

Fase de lectura 

Read phase 

Fase de validación 

Validation phase 
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Fase deshacer 

Undo phase 

Fase rehacer 

Redo phase 

Fast Path de IMS 

IMS Fast Path 

Fenómeno fantasma 

Phantom phenomenon 

Fiabilidad 

Reliability 

Ficticio 

Dummy 

Fila 

Row 

Filas ejemplo 

Example rows 

Fin-de-registro 

End-of-record 

Firma digital 

Digital signature 

Físico 

Physical 

Flujo de tareas 

Task flow 

Flujo de trabajo 

Workflow 

Flujo de trabajo de transacciones 

Transaction workflow 

FNBC (Forma normal de Boyce-Codd) 

Boyce-Codd normal form (BCNF) 

FNDC (Forma normal de dominios y claves) 

Domain-key normal form (DKNF) 

FNRP (Forma normal de reunión por proyección) 

Project-join normal form (PJNF) 

Forma normal 

Normal form 

Forma normal de Boyce-Codd (FNBC) 

Boyce-Codd normal form (BCNF) 

Forma normal de dominios y claves (FNDC) 

Domain-key normal form (DKNF) 

Forma normal de reunión por proyección (FNRP) 

Project-join normal form (PJNF) 

Formatos de datos multimedia 

Multimedia data formats 

Formulario 

Form 

Fortran 

Fortran 

Forzar el registro histórico 

Fog forcé 

Fraccionamiento de costes 

Downsizing 

Fragmentación 

Fragmentation 

Fragmentación de datos 

Data fragmentation 

Fragmentación horizontal 

Horizontal fragmentation 

Fragmentación mixta 

Mixed fragmentation 

Fragmentación vertical 

Vertical fragmentation 

Fragmentar 

Fragment 

Fragmento 

Fragment 

Fragmentos y réplicas 

Fragment and replicate 

Fragmentos y réplicas asimétricos 

Asymmetric fragment and replicate 

Función de agregación 

Aggregation function 

Función de agregación count 

Count aggregate function 

Función de asociación 

Hash function 

Función de compatibilidad 

Compatibility function 

Función monótona 

Monotonic function 

Funciones codificadas por el usuario 

User-coded functions 

Fundamentos de bases de datos 

Database System Concepts 
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Fusión 

Coalescence 

Fusionar 

Coalesce 

GAD (Grafo acíclico dirigido) 

Directed acyclic graph (DAG) 

Ganancia de velocidad 

Speedup 

Ganancia de velocidad lineal 

Linear speedup 

Ganancia de velocidad sublineal 

Sublinear speedup 

Generalización entidad-relación 

Entity-relationship generalization 

Gestión de la memoria intermedia 

Buffer management 

Gestión de transacciones 

Transaction management 

Gestión del flujo de trabajo 

Workflow management 

Gestor de almacenamiento 

Storage manager 

Gestor de colas 

Queue manager 

Gestor de control de concurrencia 

Concurrency-control manager 

Gestor de la memoria intermedia 

Buffer manager 

Gestor de recursos 

Resource manager 

Gestor de transacciones locales 

Local transaction manager 

Gopher 

Gopher 

Grado 

Degree 

Grado de relevancia 

Degree of relevance 

Grado de salida 

Fan-out 

Grafo 

Graph 

Grafo acíclico dirigido (GAD) 

Directed acyclic graph (DAG) 

Grafo construido 

Constructed graph 

Grafo de autorización 

Authorization graph 

Grafo de dependencia 

Dependency graph 

Grafo de espera 

Wait-for graph 

Grafo de espera local 

Local wait-for graph 

Grafo de histograma 

Histogram graph 

Grafo de la base de datos 

Database graph 

Grafo de precedencia 

Precedence graph 

Grafo de precedencia etiquetado 

Labeled precedence graph 

Grafo real 

Real graph 

Granularidad 

Granulan ty 

Granularidad de los bloqueos 

Granularity locks 

Granularidad fina 

Fine granularity 

Granularidad gruesa 

Coarse granularity 

Granularidad múltiple 

Múltiple granularity 

Grupo 

Group 

Grupo conjunto de expertos en imágenes 

Joint picture experts group (JPEG) 

Grupo de acceso SQL 

SQL Access Group 

Grupo de expertos en películas 

Motion picture experts group (MPEG) 

Grupo de gestión de bases de datos de objetos 

Object database management group (ODMG) 
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Grupo de gestión de objetos 

Object management group (OMG) 

Grupo de trabajo sobre bases de datos 

Database Task Group 

Hecho 

Fact 

Herencia 

Inheritance 

Herencia de atributos 

Attribute inheritance 

Herencia de atributos entidad-relación 

Entity-relationship attribute inheritance 

Herencia múltiple 

Múltiple inheritance 

Heurística 

Heuristic 

Hijo (o miembro) 

Child (or member) 

Hipertexto 

Hypertext 

Histograma 

Histogram 

Hora universal coordinada 

Universel temps coordoné (UTC) 

HyperCard 

HyperCard 

Idempotente 

Idempotent 

Identificador de objeto 

Object identifier (OID) 

Identificador de objeto 

OID (Objects identifier) 

Identificador físico de objeto 

Physical object identifier 

Identificador lógico de objeto 

Logical object identifier 

Identificador único 

Unique identifier 

Identificar 

Identify 

Id-tupla 

Tuple-id 

Igualdad 

Equality 

Igualdad basada en la clave 

Equality on key 

Igualdad basada en un atributo no clave 

Equality on nonkey 

Impaciente 

Eager 

Implementación 

Implementation 

Implementar 

Implement 

Implicadas lógicamente 

Logically implied 

Implícito 

Implicit 

Inanición 

Starvation 

Inclusión innecesaria 

False positive 

Inconsistencia de datos 

Data inconsistency 

Incorporado 

Embedded 

Independencia de datos 

Data independence 

Independiente 

Independent 

índice 

Index 

índice asociativo 

Hash Índex 

índice compuesto 

Composite Índex 

índice con agrupación 

Clustering Índex 

índice de árbol B 

B-tree Índex 

índice de árbol B + 

B + -tree índex 

índice de informes técnicos de informática 

Computer Science Technical Report Index 
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índice de organización de archivos secuenciales 

Sequential file organization Índex 

índice del árbol B + 

Index B + -tree 

índice del texto completo 

Full-text Índex 

índice denso 

Dense Índex 

índice disperso 

Sparse Índex 

índice invertido 

Inverted Índex 

índice multinivel 

Multilevel índex 

índice ordenado 

Ordered índex 

índice primario 

Primary índex 

índice secundario 

Secondary índex 

índice sin agrupación 

Nonclustering índex 

Inferir 

Infer 

Información geométrica 

Geometric information 

Informática portátil 

Mobile-computing 

Informe de invalidación 

Invalidation report 

Ingeniería del software asistida por computadora 

CASE (Computer-aided software engineering) 

Ingeniería del software asistida por computadora 

Computer-aided software engineering (CASE) 

Iniciar 

Start 

Inicio 

Startup 

Inmediata 

Immediate 

Inserción 

Insertion/ Pushing 

Instituto de ingenieros eléctricos y electrónicos 

Institute for electrical and electronical engineers (IEEE) 

Instituto de normalización nacional americano 

American national standards institute (ANSI) 

Instrucción 

Sentence 

Instrucción revoke 

Revoke statement 

Integridad 

Integrity 

Integridad de las bases de datos 

Database integrity 

Integridad de los datos 

Data integrity 

Integridad referencial 

Referential integrity 

Integridad referencial en el lenguaje SQL 

SQL language referencial integrity 

Interactivo 

On-line 

Interbloqueo 

Deadlock 

Interconexión de pequeños sistemas informáticos 

Small computer-system interconnect (SCSI) 

Interconexión hipercubo 

Hypercube interconnection 

Interfaces de usuario 

User interfaces 

Interfaz (f.) 

Interface 

Interfaz de bases de datos para arquitecturas de aplicación 
a sistemas 

System application architecture database interface (SAA-SQL) 

Interfaz de programación de aplicaciones 

Application programming interface (API) 

Interfaz del nivel de llamadas 

Call-level interface (CLI) 

Interfaz gráfica de usuario 

Graphical user interface 

Interfaz para formularios 

Form interface 
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Interfaz RPC para transacciones 

Transactional RPC interface 

Interferencia 

Interference 

Interna (reunión) 

Inner 

Internet 

Internet 

Interno 

Intemal 

Intersección 

Intersection 

Intersección de conjuntos 

Set intersection 

Intervalo 

Interval 

Invocar un método 

Invoke a method 

Iterador 

Iterator 

Java 

Java 

Jerarquía 

Hierarchy 

Jerarquía de clasificación 

Classification hierarchy 

Jerarquía de continentes 

Containment hierarchy 

L4G (Lenguaje de cuarta generación) 

Fourth-generation language (4GL) 

Laboratorio de Investigación de San José 

San José Research Center 

LDD (Lenguaje de definición de datos) 

Data-definition language (DDL) 

Lectura repetible 

Repeatable read 

Legal 

Legal 

Lenguaje anfitrión 

Host language 

Lenguaje de consulta incorporado 

Embedded query language 

Lenguaje de consultas 

Query language 

Lenguaje de consultas temporales 

Temporal query language 

Lenguaje de control de trabajos 

Job control language (JCL) 

Lenguaje de cuarta generación (L4G) 

Fourth-generation language (4GL) 

Lenguaje de definición de datos (LDD) 

Data-definition language (DDL) 

Lenguaje de definición de objetos 

Object definition language (ODL) 

Lenguaje de descripción de interfaces 

Interface description language (IDL) 

Lenguaje de manipulación de datos (LMD) 

Data-manipulation language (DML) 

Lenguaje de marcas de hipertexto 

Hypertext markup language (HTML) 

Lenguaje de marcas de texto 

Text-markup language 

Lenguaje de marcas extensible 

XML (Extensible Markup Language) 

Lenguaje de programación persistente 

Persistent programming language 

Lenguaje estructurado de consultas 

Structured query language (SQL) 

Lenguaje incorporado 

Embedded language 

Lenguaje no procedimental 

Nonprocedural language 

Lenguaje normalizado de marcas generalizado 

Standard generalized markup language (SGML) 

Lenguaje procedimental 

Procedural language 

Lenguaje SQL Gupta 

Gupta SQL languages 

Lenguaje SQL incorporado 

Embedded SQL language 

Liberación de bloqueos 

Lock deescalation 

Línea 

Line 
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Lista de atributos 

Attribute list 

Lista de privilegios 

Privilege list 

Lista enlazada 

Linked list 

Lista libre 

Free list 

Lista-deshacer 

Undo-list 

Lista-rehacer 

Redo-list 

Literal negativo 

Negative literal 

Literal positivo 

Positive literal 

LMD (Lenguaje de manipulación de datos) 

Data-manipulation language (DML) 

Localizador universal de recursos 

Universal resource locator (URL) 

Lotus Notes 

Lotus Notes 

Llamada a procedimientos remotos 

Remote-procedure-call (RPC) 

Llamada a procedimientos remotos de transacciones 

Transactional remóte procedure cali 

Manipulación de datos 

Data manipulation 

Máquina de bases de datos de Teradata 

Teradata database machine 

Máquina de grano fino 

Fine-grain machine 

Máquina masivamente paralela 

Massively parallel machine 

Máquinas paralelas de grano fino 

Fine-granularity parallel machines 

Marca temporal 

Time stamp 

Marcar 

Checkin 

Materialización 

Materialization 

Materializar 

Materialize 

Mecanismo de llamadas a procedimientos remotos 

Remote-procedure-call mechanism 

Media armónica 

Harmonic mean 

Memoria compartida 

Shared memory 

Memoria flash 

Flash memory 

Memoria intermedia 

Buffer 

Memoria intermedia con traducción anticipada 

Translation lookaside buffer (TLB) 

Memoria intermedia de disco 

Disk buffer 

Memoria intermedia de la base de datos 

Database buffer 

Memoria no volátil de acceso aleatorio (RAM no volátil) 

Nonvolatile random-access memory (nonvolatile RAM) 

Memoria principal 

Main memory 

Memoria sólo de lectura en disco compacto 

Compact-disk read-only memory (CD-ROM) 

Memoria sólo de lectura programable y borrable eléctricamente 

Electrically erasable programmable read-only memory 
(EEPROM) 

Memoria virtual 

Virtual memory 

Memoria virtual distribuida 

Distributed virtual-memory 

Mensaje 

Message 

Metadatos 

Metadata 

Método 

Method 

Mezcla de n vías 

N -way merge 

Mezcla-ordenación externa 

Extemal sort-merge 
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Mezcla-ordenación paralela externa 

Parallel extemal sort-merge 

Mezclar 

Merge 

Microcomputadora 

Set-top box Computer 

Miembro (o hijo) 

Member (or child) 

Modelo de datos 

Data model 

Modelo de datos entidad-relación 

Entity-relationship data model 

Modelo de datos físicos 

Physical data model 

Modelo de datos orientado a objetos 

Object-Oriented data model 

Modelo de disco compartido 

Shared-disk model 

Modelo de memoria por marcos 

Frame-memory model 

Modelo de navegación 

Navigational model 

Modelo de operador de intercambio 

Exchange-operator model 

Modelo de proceso por cliente 

Process-per-client model 

Modelo de red 

NetWork model 

Modelo de servidor único 

Single-server model 

Modelo de simulación de rendimiento 

Performance-simulation model 

Modelo de transacciones distribuidas 

Distributed transaction model 

Modelo de unificación 

Unifying model 

Modelo de varios servidores y un solo encaminador 

Many-server, single-router model 

Modelo de varios servidores y varios encaminadores 

Many-server, many-router model 

Modelo entidad-relación 

Entity-relationship model 

Modelo E-R (entidad-relación) 

E-R model (Entity-relationship model) 

Modelo jerárquico 

Hierarchical model 

Modelo orientado a objetos 

Object-Oriented model 

Modelo relacional 

Relational model 

Modelo relacional anidado 

Nested relational model 

Modelo suceso-condición-acción 

Event-condition-action model 

Modelos de datos relaciónales 

Relational data models 

Modelos de datos relaciónales orientados a objetos 

Object-relational data models 

Modelos lógicos basados en objetos 

Object-based data models 

Modelos lógicos basados en registros 

Record-based data models 

Modelos relaciónales orientados a objetos 

Object relational models 

Módem 

Modem 

Modificación de bases de datos 

Modification of databases 

Modificación diferida 

Deferred modification 

Modificación no comprometida 

Uncommited modification 

Modo de actualización 

Update mode 

Modo de bloqueo compartido 

Shared mode locks 

Modo de bloqueo intencional 

Intention lock mode 

Modo de transferencia asincrono (MTA) 

Asynchronous transfer mode (ATM) 

Modo intencional-compartido (IC) 

Intention-shared (IS) mode 

Modo intencional-exclusivo (IX) 

Intention-exclusive (IX) mode 
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Modo intencional-exclusivo y compartido (IXC) 

Módulo 
Monitor CICS 

Monitor de teleprocesamiento 
Monitor Encina 
Monitor IMS 
Monitores RTR 
Monótona 

Motor de ejecución de consultas 
MTA (Modo de transferencia asincrono) 

Multiconjunto 
Multienhebramiento 
Multinivel 
Multiprogramación 
Multitarea 
Multivalorado 
Multiversión 
Nivel conceptual 
Nivel de vistas 
Nivel físico 
Nivel lógico 
Nivel más alto 
Nivel más bajo 
Niveles de RAID 
No conocido 
No segura 
Nodo 

Nodo remoto copia de seguridad 

Nodo secundario 

Norma 

Norma anticipativa 
Norma de cifrado de datos 
Norma de facto 
Norma del lenguaje SQL 
Norma formal 
Norma MPEG-1 
Norma MPEG-2 

Norma para el procesamiento de transacciones distribuidas 
X/Open 

Norma reaccionaria 

Normalización 

Nulo 


Shared and intention-exclusive (SIX) mode 

Module 

CICS monitor 

Teleprocessing monitor 

Encina monitor 

IMS monitor 

RTR monitors 

Monotonic 

Query-execution engine 
Asynchronous transfer mode (ATM) 

Multiset 
Multithreading 
Multilevel 
Multiprogramming 
Multitasking 
Multivalued 
Multiversión 
Conceptual level 
View level 
Physical level 
Logical level 
Higher-level 
Lower-level 
RAID levels 
Not known 
Unsafe 

Vertex (graph)/Node (network) 

Remóte backup site 
Secondary site 
Standard 

Anticipatory standard 

Data encryption standard (DES) 

De facto standard 
SQL language standard 
Formal standard 
MPEG-1 standard 
MPEG-2 standard 

X/open distributed transaction processing standard 


Reactionary standard 

Normalization 

Nuil 
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Número de bloque 

Block number 

Número de transferencias de bloques de disco 

Number of block transfers from disk 

Object SQL 

Object SQL (OSQL) 

Objeto 

Object 

Objeto complejo 

Complex object 

Objeto compuesto 

Composite object 

Objeto en binario de gran tamaño 

Binary large object (blob) 

Observar 

Monitor 

Omisión incorrecta 

False drop 

Operación append 

Append operation 

Operación asignación 

Assignment operation 

Operación by 

By operation 

Operación de agregación 

Aggregation operation 

Operación delete 

Delete operation 

Operación diferencia de conjuntos 

Set-difference operation 

Operación división 

División operation 

Operación except 

Except operation 

Operación from 

From operation 

Operación grant 

Grant operation 

Operación group by 

Group by operation 

Operación intersección 

Intersection operation 

Operación intersect 

Intersect operation 

Operación join 

Join operation 

Operación lógica 

Logical operation 

Operación lookup 

Lookup operation 

Operación producto cartesiano 

Cartesian-product operation 

Operación proyección 

Project operation 

Operación proyección generalizada 

Generalized-projection operation 

Operación range of 

Range of operation 

Operación redo 

Redo operation 

Operación relacional 

Relational operation 

Operación rename 

Rename operation 

Operación replace 

Replace operation 

Operación select 

Select operation 

Operación undo 

Undo operation 

Operación unión 

Union operation 

Operación where 

Where operation 

Operaciones de cadena 

String operations 

Operaciones de conjuntos 

Set operations 

Operador data-cube 

Data-cube operator 

Operador de agregación 

Aggregation operator 

Optimización basada en el coste 

Cost-based optimization 
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Optimización con tableaux 

Tableau optimization 

Optimización de consultas 

Query optimization 

Oracle 7 

Oracle 7 

Orden 

Command 

Orden de secuencialidad 

Serializability order 

Orden descendente 

Descending order 

Orden lexicográfico 

Lexicographic ordering 

Orden más significativo 

Big-endian form 

Orden menos significativo 

Little-endian form 

Ordenación externa 

Extemal sorting 

Ordenación paralela 

Parallel sort 

Ordenación rápida 

Quicksort 

Ordenación topológica 

Topological sorting 

Ordenes de reunión en profundidad por la izquierda 

Left-deep join orders 

Organización asociativa de archivos 

Hashing file organization 

Organización de archivos 

File organization 

Organización de archivos con árboles B + 

B + -tree file organization 

Organización de archivos en agrupaciones 

Clustering file organization 

Organización de archivos en montículo 

Heap file organization 

Organización de códigos de corrección de errores tipo memoria 

Memory-style error-correcting-code organization (ECC) 

Organización de paridad con bits entrelazados 

Bit-interleaved parity organization 

Organización de paridad con bloques entrelazados 

Block-interleaved parity organization 

Organización internacional de normalización 

International standards organization (ISO) 

Organizar lógicamente los documentos 

Organize documents logically 

Padre (o propietario) 

Parent (or owner) 

Página 

Page 

Página inicial 

Home page 

Paginación en la sombra 

Shadow paging 

Palabra clave 

Keyword 

Palabras de parada 

Stop words 

Papel 

Role 

Paralelismo de datos 

Data parallelism 

Paralelismo de E/S 

I/O parallelism 

Paralelismo de encauzamiento 

Pipelined parallelism 

Paralelismo de grano grueso 

Coarse-granularity parallelism 

Paralelismo de particiones 

Partitioned parallelism 

Paralelismo en consultas 

Intraquery parallelism 

Paralelismo en operaciones 

Intraoperation parallelism 

Paralelismo entre consultas 

Interquery parallelism 

Paralelismo entre operaciones 

Interoperation parallelism 

Paralelismo independiente 

Independent parallelism 

Parámetro 

Parameter 
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Parámetros ajustables 

Tunable parameters 

Parcial 

Pardal 

Parte visible al usuario 

Front-end 

Partición 

Paitition (n.) 

Participación 

Participation 

Pascal 

Pascal 

Paso 

Step 

Paso de mensaje 

Sending a message 

Pathway 

Pathway 

Perdido 

Missing 

Persistencia de los objetos 

Persistence of objects 

Pertenencia al conjunto 

Set membership 

Pestillo 

Latch 

Pista 

Track 

Plan de ejecución de la consulta 

Query-execution plan 

Plan de evaluación de la consulta 

Query-evaluation plan 

Planificación 

Scheduling 

Planificación del brazo del disco 

Disk-arm-scheduling 

Planificación no recuperable 

Nonrecoverable schedule 

Planificaciones de conflictos 

Conflict schedules 

Planificaciones recuperables 

Recoverable schedules 

Planificaciones sin cascada 

Cascadeless schedules 

Planificar 

Schedule 

Plantilla 

Témplate 

Plato 

Platter 

Población 

Population 

Polígonos cerrados 

Closed polygons 

Por líneas 

Ráster 

Posibilidad 

Possibility 

Posibilidad de sustitución 

Substitutability 

Postgres 

Postgres 

PostScript 

PostScript 

PowerBuilder 

PowerBuilder 

Práctico 

Convenient 

Precedencia de grafos 

Graph precedence 

Precedencia de grafos etiquetados 

Labeled graph precedence 

Preceder 

Precede 

Precio por TPS 

Price per TPS 

Precisión 

Precisión 

Precompilador del LMD 

DML precompiler 

Preextracción 

Prefetching 

Prefijo común de la función de asociación 

Common hash prefix 
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Preservar la equivalencia 

Preserve equivalence 

Prevención de interbloqueos 

Deadlock prevention 

Primera forma normal (1FN) 

First normal form (INF) 

Primitivas de evaluación 

Evaluation primitives 

Primo 

Prime 

Privilegio 

Privilege 

Privilegio de referencias 

Reference privilege 

Privilegios de referencia del lenguaje SQL 

SQL language reference privilege 

Probar 

Probe 

Problema de bloqueo 

Blocking problem 

Problema de coherencia caché 

Cache-coherency problem 

Problema del mantenimiento de las vistas 

View-maintenance problem 

Problemas NP-completos 

NP-complete problems 

Procesador de consultas 

Query processor 

Procesamiento 

Processing 

Procesamiento de consultas 

Query processing 

Procesamiento de transacciones 

Transaction processing (TP) 

Procesamiento distribuido de consultas 

Distributed query processing 

Procesamiento en conexión analítico 

On-line analytical processing (OLAP) 

Procesamiento en conexión de transacciones 

On-line transaction processing (OLTP) 

Proceso 

Process 

Procesos del servidor para varias aplicaciones 

Múltiple application-server processes 

Productividad 

Throughput 

Producto cartesiano 

Cartesian product 

Programa 

Program 

Programación orientada a objetos 

Object oriented programming (OOP) 

Programas de aplicación 

Application programs 

Prolog 

Prolog 

Propiedades ACID 

ACID properties 

Propietario 

Own 

Propietario (o padre) 

Owner (or parent) 

Protocolo basado en el bloqueo 

Lock protocol 

Protocolo basado en grafos 

Graph-based protocol 

Protocolo basado en la marca temporal 

Timestamp-based protocol 

Protocolo de árbol 

Tree protocol 

Protocolo de bloqueo 

Locking protocol 

Protocolo de bloqueo de dos fases 

Two-phase locking protocol 

Protocolo de bloqueo de dos fases multiversión 

Multiversión two-phase locking protocol 

Protocolo de bloqueo de granularidad múltiple 

Multiple-granularity locking protocol 

Protocolo de bloqueo del árbol 

Tree-locking protocol 

Protocolo de bloqueo estricto de dos fases 

Strict two-phase locking protocol 

Protocolo de bloqueo riguroso de dos fases 

Rigorous two-phase locking protocol 
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Protocolo de bosque 

Forest protocol 

Protocolo de compromiso 

Commit protocol 

Protocolo de compromiso de dos fases (C2F) 

Two-phase commit (2PC) protocol 

Protocolo de compromiso de tres fases (C3F) 

Three-phase commit (3PC) protocol 

Protocolo de control de la concurrencia 

Concurrency-control protocol 

Protocolo de fallo del coordinador 

Coordinator-failure protocol 

Protocolo de interfaz cliente-servidor 

Client-server interface protocol 

Protocolo de lectura global 

Global-read protocol 

Protocolo de lectura local 

Local-read protocol 

Protocolo de lectura y escritura global y lectura local 

Global-read-write/local-read protocol 

Protocolo de ordenación por marcas temporales 

Timestamp-ordering protocol 

Protocolo de prevención de interbloqueos 

Deadlock-prevention protocol 

Protocolo de transferencia de archivos 

File transfer protocol (FTP) 

Protocolo de validación 

Validation protocol 

Protocolo global de lectura y escritura 

Global-read-write protocol 

Protocolo para transferencia de hipertexto 

HyperText transfer protocol (F1TTP) 

Protocolo sesgado 

Biased protocol 

Proyección 

Projection 

Proyección generalizada 

Generalized-projection 

Proyección temporal 

Temporal projection 

Proyectar 

Project 

Prueba de rendimiento 

Performance benchmark 

Prueba de secuencialidad 

Testing for serializability 

Puesto 

Mart 

Puntero 

Pointer 

Puntero colgante 

Dangling pointer 

Puntero oculto 

Flidden pointers 

Puntero persistente 

Persistent pointer 

Punteros internos de memoria 

In-memory pointers 

Punto de bloqueo 

Lock point 

Punto de revisión 

Checkpoint 

Punto de revisión difuso 

Fuzzy checkpoint 

Punto fijo 

Fixpoint 

Punto fijo del lenguaje Datalog 

Datalog language fixpoint 

Quel 

Quel 

Rango de las consultas 

Query range 

Raro 

Extraneous 

RDSI (Red digital de servicios integrados) 

Integrated Services digital network (ISDN) 

Reasignación de los sectores dañados 

Remapping of bad sectors 

Recogida de basura 

Garbage collection 

Recopilación de datos 

Data mining 

Recopilación de datos dirigida por el usuario 

User-guided data mining 
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Recubrimiento canónico 

Canonical cover 

Recuperabilidad 

Recoverability 

Recuperabilidad de elementos de datos de gran tamaño 

Large data Ítems recoverability 

Recuperabilidad de planificaciones 

Recoverability schedule 

Recuperación 

Recaí l/Recovcry 

Recuperación al reiniciar 

Restart recovery 

Recuperación basada en la semejanza 

Similarity-based retrieval 

Recuperación de fallos 

Failure recovery 

Recuperación de fallos basada en el registro histórico 

Log-based failure recovery 

Recuperación de información basada en palabras clave 

Keyword-based information retrieval 

Recuperación de interbloqueos 

Deadlock recovery 

Recuperación de la información 

Information retrieval 

Recuperar 

Recover 

Recursividad 

Recursion 

Recursividad del lenguaje Datalog 

Datalog language recursion 

Recursivo 

Recursive 

Recurso de gestión de consultas 

Query management facility (QMF) 

Red conectada par cialmente 

Partially connected network 

Red de área amplia 

Wide-area network (WAN) 

Red de área local 

Local-area network (LAN) 

Red de computadoras 

Computer network 

Red de interconexión 

Interconnection network 

Red digital de servicios integrados (RDSI) 

Integrated Services digital network (ISDN) 

Redes informáticas de larga distancia 

Long-distance Computer networks 

Redistribuir 

Redistribute 

Redundancia 

Redundancy 

Redundancia de datos 

Data redundancy 

Referencia 

Reference 

Registro 

Record 

Registro de actualización del registro histórico 

Update log record 

Registro de compromiso del registro histórico 

Commit log record 

Registro del índice 

Index record 

Registro físico del registro histórico 

Physical log record 

Registro histórico 

Log 

Registro histórico con memoria intermedia 

Log-record buffering 

Registro histórico de escritura anticipada 

Write-ahead logging (WAL) 

Registro histórico físico 

Physical logging 

Registro histórico lógico 

Logical logging 

Registro rehacer del registro histórico 

Redo log record 

Registro virtual 

Virtual record 

Registros de longitud fija 

Fixed-length records 

Registros de longitud variable 

Variable-length records 
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Regla 

Rule 

Regla de escritura de Thomas 

Thomas’ write rule 

Regla de la aumentatividad 

Augmentation rule 

Regla de la aumentatividad multivalorada 

Multivalued augmentation rule 

Regla de la complementariedad 

Complementation rule 

Regla de la descomposición 

Decomposition rule 

Regla de la diferencia 

Difference rule 

Regla de la fusión 

Coalescence rule 

Regla de la intersección 

Intersection rule 

Regla de la pseudotransitividad 

Pseudotransitivity rule 

Regla de la reflexividad 

Reflexivity rule 

Regla de la transitividad 

Transitivity rule 

Regla de la transitividad multivalorada 

Multivalued transitivity rule 

Regla de la unión 

Union rule 

Regla de la unión multivalorada 

Multivalued unión rule 

Regla de réplicas 

Replication rule 

Reglas activas 

Active rules 

Reglas completas 

Complete rules 

Reglas correctas 

Sound rules 

Reglas de asociación 

Association rules 

Reglas de Datalog 

Datalog rules 

Reglas de equivalencia 

Equivalence rules 

Reglas del lenguaje Datalog 

Datalog language rules 

Rehacer 

Redo 

Relación 

Relation/Relationship 

Relación bitemporal 

Bitemporal relation 

Relación de identificación 

Identifying relationship 

Relación de vistas 

View relation 

Relación instantánea 

Snapshot relation 

Relación temporal 

Temporal relation 

Relacional anidado 

Nested relational 

Relaciones de consultas 

Queries relations 

Relaciones derivadas 

Derived relations 

Relevo 

Handoff 

Relevo del control 

Handoff of control 

Reloj del sistema 

System dock 

Reloj lógico 

Logical dock 

Remitir 

Submit 

Rendimiento 

Performance 

Rendimiento de reconstrucción 

Rebuild performance 

Renombramiento 

Renaming 

Renombrar 

Rename 
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Reorganizar 

Reorganize 

Repetición de información 

Repetition of information 

Repetición de la historia 

Repeating history 

Réplica completa 

Full replication 

Réplica de datos 

Data replication 

Representación en cadenas de bytes 

Byte-string representation 

Representación en longitud fija 

Fixed-length representation 

Representación tabular 

Tabular representation 

Requisito 

Requirement 

Rescate 

Swizzling 

Rescate de punteros 

Pointer swizzling 

Rescate hardware 

Hardware swizzling 

Rescate software 

Software swizzling 

Resolución 

Resolution 

Respuesta 

Response 

Restricción 

Restriction 

Restricción de completitud 

Completeness constraint 

Restricción de integridad referencial 

Referential integrity constraint 

Restricción general 

General constraint 

Restricción sobre el carácter disjunto 

Disjointness constraint 

Restricciones con condiciones definidas 

Conditions-defined constraints 

Restricciones de autorización 

Authorization restrictions 

Restricciones de completitud 

Constraints completeness 

Restricciones de consistencia 

Consistency constraints 

Restricciones de diseño 

Design constraints 

Restricciones de diseño definidas por las condiciones 

Condition-defined design constraints 

Restricciones de diseño definidas por los atributos 

Attribute-defined design constraints 

Restricciones de diseño definidas por los usuarios 

User-defined design constraints 

Restricciones de dominio 

Domain constraints 

Restricciones de integridad 

Integrity constraints 

Restricciones de integridad referencial 

Referencial-integrity constraints 

Resumen 

Summary 

Retículo 

Lattice 

Retirada en cadena 

Cascading of the revoke 

Retroceder 

Rollback (v.) 

Retroceso 

Rollback («.) 

Retroceso de la transacción 

Transaction rollback 

Retroceso en cascada 

Cascading rollback 

Reunión 

Join 

Reunión con fragmentos y réplicas 

Fragment-and-replicate join 

Reunión con pérdida 

Lossy join 

Reunión cruzada 

Cross join 
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Reunión de banda 

Band join 

Reunión de unión 

Union join 

Reunión en bucle anidado 

Nested-loop join 

Reunión en bucle anidado indexada 

Indexed nested-loop join 

Reunión encauzada 

Pipelined join 

Reunión espacial 

Spatial join 

Reunión extema 

Outer-join 

Reunión externa completa 

Full outer join 

Reunión extema por la derecha 

Right outer join 

Reunión extema por la izquierda 

Left outer join 

Reunión fraccionada 

Join partitioning 

Reunión natural 

Natural join 

Reunión paralela 

Parallel join 

Reunión por mezcla-ordenación 

Sort-merge join 

Reunión por proyección 

Project join 

Reunión sin pérdida 

Lossless join 

Reunión temporal 

Temporal join 

Reuniones dependientes 

Dependent joins 

Robo de información 

Theft of information 

Robustez 

Robustness 

Saga 

Saga 

Salida forzada 

Forced output 

Satisfacer 

Satisfy 

Se cumple en R 

Holds on R 

Sector 

Sector 

Secuencia 

Run 

Secuenciable en cuanto a conflictos 

Conflict serializable 

Secuenciable en cuanto a vistas 

View serializable 

Secuencial 

Serial 

Secuencialidad 

Serializability 

Secuencialidad de dos niveles 

Two-level serializability 

Secuencialidad en cuanto a conflictos 

Conflict serializability 

Secuencialidad en cuanto a vistas 

View serializability 

Segunda forma normal (2FN) 

Second normal form (2NF) 

Seguridad 

Safety 

Seguridad de la base de datos 

Database security 

Seguridad en el nivel de la red 

Network-level security 

Selección 

Selection 

Selección conjuntiva 

Conjunctive selection 

Selección conjuntiva mediante la intersección de identificadores 

Conjunctive selection by intersection of identifiers 

Selección conjuntiva utilizando un índice 

Conjunctive selection using one Índex 

Selección conjuntiva utilizando un índice compuesto 

Conjunctive selection using composite Índex 
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Selección del plan de acceso 

Access-plan-selection 

Selección disyuntiva 

Disjunctive selection 

Selección disyuntiva mediante la unión de identificadores 

Disjunctive selection by unión of identifiers 

Selección temporal 

Temporal selection 

Seleccionar 

Select 

Selectividad 

Selectivity 

Semántica de estratificación modular 

Modular-stratification semantics 

Semántica de un programa 

Semantics of a program 

Semántica de una regla 

Semantics of a rule 

Semejante 

Similar 

Semirreunión 

Semi join 

Servidor de nombres 

Ñame server 

Servidor de vídeo 

Video server 

Servidor Web 

Web server 

Sesgar 

Skew 

Sesgo 

Skew 

Sesgo de ejecución 

Execution skew 

Sesgo de la división 

Partition skew 

Sesgo de la división 

Skew partitioning 

Sesgo de los valores 

Attribute-value skew 

Sesgo de los valores de los atributos 

Attribute valué skew 

SGBD (Sistema gestor de bases de datos) 

Database management System (DBMS) 

Simula 

Simula 

Sin compromiso de lectura 

Read uncommited 

Sin conexión 

Off-line 

Sinónimo 

Synonym 

Sintetizar 

Synthesize 

Sistema ampliable 

Escalable System 

Sistema con múltiples bases de datos 

Multidatabase system 

Sistema de archivos 

File system 

Sistema de archivos basado en el registro histórico 

Log-based file system 

Sistema de bases de datos activas 

Database active system 

Sistema de bases de datos en memoria principal 

Main-memory database system 

Sistema de bases de datos Illustra 

Illustra database system 

Sistema de bases de datos Ingres 

Ingres database system 

Sistema de colas 

Queue system 

Sistema de disco compartido 

Shared-disk system 

Sistema de información de área amplia 

Wide area information system (WAIS) 

Sistema de localización global 

Global positioning system (GPS) 

Sistema de procesamiento de archivos 

File-processing system 

Sistema de tiempo real 

Real-time system 

Sistema de usuario único 

Single user system 
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Sistema Gamma 

Gamma System 

Sistema gestor de bases de datos (SGBD) 

Database management system (DBMS) 

Sistema gestor de flujos de trabajo 

Workflow-management system 

Sistema gestor de información de IBM 

Information management system (IMS) 

Sistema Grace 

Grace system 

Sistema informático 

Computer system 

Sistema ininterrumpido 

Non-stop system 

Sistema masivamente paralelo 

Massively parallel system 

Sistema monousuario típico 

Typical single-user system 

Sistema multiprocesador de memoria compartida 

Shared-memory multiprocessor system 

Sistema multiusuario 

Multiuser Systems 

Sistema multiusuario típico 

Typical multiuser system 

Sistema paralelo de bases de datos 

Parallel database system 

Sistema paralelos 

Parallel system 

Sistema relacional 

Relational system 

Sistema relacional orientados a objetos 

Object-relational system 

Sistema servidor 

Server system 

Sistema servidor de consultas 

Query-server system 

Sistema servidor de transacciones 

Transaction server system 

Sistema subyacente 

Back-end 

Sistemas clientes 

Client systems 

Sistemas de ayuda para las decisiones 

Decision-support systems 

Sistemas de bases de datos cliente-servidor 

Client-server database systems 

Sistemas de bases de datos multiversión 

Multiversión database systems 

Sistemas de colas 

Queueing systems 

Sistemas de descubrimiento del conocimiento 

Knowledge-discovery systems 

Sistemas de información geográfica 

Geographic information systems 

Sistemas de información para oficinas 

Office information systems (OIS) 

Sistemas de transacciones de alto rendimiento 

High-performance transaction systems 

Sistemas de visualización de datos 

Data-visualization systems 

Sistemas distribuidos de bases de datos 

Distributed database systems 

Sistemas distribuidos de hipertexto 

Distributed hypertext systems 

Sistemas distribuidos de información 

Distributed information systems 

Sistemas distribuidos de información en Internet 

Distributed Internet information systems 

Sistemas distribuidos de información Gopher 

Distributed Gopher information systems 

Sistemas distribuidos de información World Wide Web 

Distributed World Wide Web information systems 

Sistemas distribuidos y heterogéneos de bases de datos 

Heterogeneous distributed database systems 

Sistemas heredados 

Legacy systems 

Sistemas hipermedia 

Hypermedia systems 

Sistemas monótonos 

Monotonic systems 

Sistemas RAID 

Redundant array of inexpensive disks systems 

Sistemas relaciónales orientados a objetos 

Object relational systems 
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Sistemas remotos de copia de seguridad 

Remóte backup Systems 

Sistemas servidores de consultas 

Queries server Systems 

Sistemas servidores de datos 

Data-server Systems 

Sistemas servidores de transacciones 

Transaction-server systems 

Smalltalk 

Smalltalk 

Sobrecarga 

Overloading 

Solapa 

Overlaps 

Solicitud 

Request 

Sólo de lectura 

Read-only 

Soporte 

Support 

Subárboles disjuntos 

Disjoint subtrees 

Subclase 

Subclass 

Subconsulta 

Subquery 

Subesquema 

Subschema 

Subexpresiones comunes 

Common subexpressions 

Subsistema de recuperación de caídas 

Crash-recovery subsystem 

Suceso 

Event 

Suceso disparador 

Triggering event 

Superclase 

Superclass 

Superclave 

Superkey 

Superusuario 

Superuser 

Suponer aborto 

Presume abort 

Suponer compromiso 

Presume commit 

Suposición de papel único 

Unique-role assumption 

Supresión de índices 

Drop indices 

Supuesto de fallo-parada 

Fail-stop assumption 

System R 

System R 

Tabla 

Table 

Tabla cruzada 

Cross-tab 

Tabla de entradas cruzadas 

Cross-tabulation 

Tabla de páginas 

Page table 

Tabla de páginas actual 

Current page table 

Tabla de páginas sombra 

Shadow page table 

Tablas combinadas 

Combined tables 

Tableau 

Tableau 

Tándem 

Tándem 

Tarea 

Task 

Técnica de actualización inmediata 

Immediate-update technique 

Técnica de bloqueo de índice 

Index-locking technique 

Técnica de compromiso en grupo 

Group-commit technique 

Técnicas de asociación dinámica 

Dynamic hashing techniques 

Técnicas de organización de archivos 

File organization techniques 
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Teoría de colas 

Queue theory 

Tercera forma normal (3FN) 

Third normal form (3NF) 

Terminación con éxito 

Successful completion 

Terminado 

Terminated 

Terminal 

Terminal 

Teselación por triangulación 

Triangulation 

Tiempo de acceso 

Access time 

Tiempo de búsqueda 

Seek time 

Tiempo de inicio 

Startup time 

Tiempo de latencia 

Latency time 

Tiempo de latencia rotacional 

Rotational latency time 

Tiempo de servicio 

Service time 

Tiempo de transacción 

Transaction time 

Tiempo límite 

Deadline 

Tiempo medio de búsqueda 

Average seek time 

Tiempo medio de latencia 

Average latency time 

Tiempo medio de reparación 

Mean time to repair 

Tiempo medio de respuesta 

Average response time 

Tiempo medio entre fallos 

Mean time to failure 

Tiempo medio entre pérdidas de datos 

Mean time to data loss 

Tiempo para finalizar 

Time to completion 

Tiempo válido 

Valid time 

Tipo colección 

Collection type 

Tipo de conexión ficticia 

Dumnry junction type 

Tipo de enlace ficticio 

Dummy link type 

Tipo de registro ficticio 

Dummy record type 

Tipo de registro Renlace 

Record type Rlink 

Tipo más específico 

Most specific type 

Tipos complejos 

Complex types 

Tipos de dominios 

Domain types 

Tipos de referencia 

Reference types 

Tipos estrictos 

Strong types 

Tipos no atómicos 

Nonatomic types 

Tolerancia ante fallos 

Fault tolerance 

Total 

Total 

Trama 

Mesh 

Transacción 

Transaction 

Transacción anidada 

Nested transaction 

Transacción compensadora 

Compensating transaction 

Transacción comprometida 

Commited transaction 

Transacción de actualización 

Update transaction 

Transacción de alto rendimiento 

Fligh-performance transaction 
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Transacción de corta duración 

Short-duration transaction 

Transacción de larga duración 

Long-duration transaction 

Transacción dudosa 

In-doubt transaction 

Transacción global 

Global transaction 

Transacción interactiva compleja 

Complex interactive transaction 

Transacción local 

Local transaction 

Transacción multinivel 

Multilevel transaction 

Transacción por minilotes 

Mini-batch transaction 

Transacciones anidadas 

Nested transactions 

Transacciones por segundo 

Transactions per second (TPS) 

Transferir 

Transfer 

Transitorio 

Transient 

Transparencia de la red 

NetWork transparency 

Tratamiento de interbloqueos 

Deadlock handling 

Tries 

Tries 

Trivial 

Trivial 

Tupia 

Tupie 

Turno rotatorio 

Round-robin 

UCP (Unidad central de procesamiento) 

Central processing unit (CPU) 

Unaria 

Unary 

Único 

Unique 

Unidad 

Unit 

Unidad central de procesamiento (UCP) 

Central processing unit (CPU) 

Unión 

Union 

Univalorados 

Single valued 

Uno seguro 

One-safe 

Usuario 

User 

Usuario normal 

Naive user 

Utilidades para presentaciones 

Presentation facilities 

Utilización 

Utilization 

Utilización de elementos de datos 

Data-item utilization 

Utilizado más recientemente 

Most recently used (MRU) 

Utilizado menos recientemente 

Least recently used (LRU) 

Valores de salida 

Output valúes 

Valores nulos 

Nuil valúes 

Variable 

Variable 

Variable de dominio 

Domain variable 

Variable de ejemplares 

Instance variable 

Variable externa 

External variable 

Variable ligada 

Bound variable 

Variable tupia 

Tupie variable 

Varias transacciones 

Múltiple transactions 
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VDD (Videodisco digital) 

Digital video disk (DVD) 

Vector de división 

Vector partitioning 

Vector de división con carga equilibrada 

Load-balanced partition vector 

Vector de versiones 

Versión vector 

Velocidad de transferencia 

Transfer rate 

Velocidad de transferencia de datos 

Data-transfer rate 

Versiones multiconjunto 

Multiset versions 

Videodisco digital (VDD) 

Digital video disk (DVD) 

Violación de la segmentación 

Segmentation violation 

Vista 

View 

Vista materializada 

Materialized view 

Vistas equivalentes 

Equivalent views 

Visualización de datos 

Data visualization 

Visualizar 

Display 

Volcado 

Dump 

Volcado de archivo 

Archival dump 

Volcado difuso 

Fuzzy dump 

Volcar 

Dump 

Volumen 

Volume 

Volver a configurar 

Reconfigure 

Web crawler 

Web crawler 

World Wide Web 

World Wide Web (WWW) 

Zeta 

Theta (0) 

Zona 

Area 
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